[vuanhphung]

ResultSlicer tracks leftovers by offset and shares a copy loop with fetchAll(), preserving chunk sizes, row order, hasMore(), and disableBuffering behavior. Initial allocation is capped at 2 ** 25 to avoid V8 dictionary arrays; sequential writes grow larger results. Negative, NaN, and fractional limits retain their previous behavior.

Validation: 1,544 unit tests pass (CODEX_CI unset), plus lint, Prettier, type checking, and build. Compared 2,000 generated slicing scenarios against main and checked every output row immediately below, at, and above the allocation threshold.

Offline benchmarks on Node v24.14.0, three alternating fresh-process runs per build: the 80,003,072-row Arrow pipeline improved from 28.3 to 12.4 ns/row (100,000-row fetches, materialization disabled, DBSQL_KERNEL_PIPELINE unset). Joining 4,096-row placeholder batches improved versus main's flat(): 40M rows 1.301 → 0.541 s; 80M rows 2.965 → 1.730 s (medians).

Live kernel benchmark using pecotesting on Medium serverless, result caching and row materialization disabled, 100,000-row chunks: medians of five fresh-process samples per build after warmup. All runs returned the expected row counts.

Query	Elapsed, main → PR	Drain, main → PR
Boolean, 80M rows	3.641 → 2.513 s	2.557 → 1.471 s
Float, 50M rows	4.800 → 4.151 s	1.718 → 1.089 s
Double, 30M rows	4.622 → 4.394 s	1.085 → 0.828 s

One PR double sample took 17.075 s elapsed / 11.903 s drain and remains included in the median.

[peco-review-bot]

✅ No issues identified by the review bot.

[peco-review-bot]

✅ No issues identified by the review bot.