GeezerVison

Each inline FetchResults row set was decompressed into a bytearray grown
on the malloc heap. The Arrow table reads it zero-copy, so ~3.7 MB per
round trip stayed live there, mixed with short-lived reply buffers; after
a large result was released glibc kept almost all of it resident (a
1.7 GB inline fetchall_arrow left ~1.6 GB). Copy each set's stream into
a private anonymous mmap instead (pre-faulted with MAP_POPULATE where
available), which goes back to the OS when the table is freed. Sets under
128 KiB and mmap failures keep the heap path.

Signed-off-by: Vu Anh Phung <[email protected]>
Co-authored-by: Isaac <[email protected]>

peco-review-bot Bot left a comment

Holding every decompressed batch until the copy needed about twice the
row set's memory, and releasing the parts did not help because glibc
keeps freed chunks resident. Reserve the map from the compressed size
instead (untouched pages cost nothing), copy each batch in as it is
decompressed, and grow the map with mremap on overflow. Platforms
without mremap continue on the heap. A 51 MB row set now converts with
no transient, as on main.

Signed-off-by: Vu Anh Phung <[email protected]>
Co-authored-by: Isaac <[email protected]>

peco-review-bot Bot left a comment

Release the unused part of the size estimate once the stream is
complete, so it no longer counts against a strict overcommit limit
while the result is alive. Use the map only where MAP_PRIVATE exists:
the heap retention is a glibc behaviour, and Windows commits anonymous
maps up front and copies on resize. Tests now assert the growth,
shrink, and heap-fallback paths are actually taken.

Signed-off-by: Vu Anh Phung <[email protected]>
Co-authored-by: Isaac <[email protected]>

peco-review-bot Bot left a comment

…a memoryview

The heap retention this works around is glibc's, so other platforms keep
the previous bytearray. When a map can't grow, copy what was written via
a memoryview instead of a temporary bytes slice.

Signed-off-by: Vu Anh Phung <[email protected]>
Co-authored-by: Isaac <[email protected]>

The tests replaced mmap.mmap on the stdlib module for the whole process.
Swap the mmap module seen by utils instead, and give the large-set
fixture an explicit check that it stays above the mmap floor.

Signed-off-by: Vu Anh Phung <[email protected]>
Co-authored-by: Isaac <[email protected]>

peco-review-bot Bot left a comment

It only reaches the MAP_PRIVATE guard where the map path is enabled.

Signed-off-by: Vu Anh Phung <[email protected]>
Co-authored-by: Isaac <[email protected]>

peco-review-bot Bot left a comment

The 1 MiB floor was compared with the 4x size estimate, so row sets
with as little as ~256 KiB of compressed data still got their own map.
Compare it with the batches' total size, a lower bound on the stream
size, so every map really is at least ~1 MiB and the VMA bound in the
comment holds.

Signed-off-by: Vu Anh Phung <[email protected]>
Co-authored-by: Isaac <[email protected]>

peco-review-bot Bot left a comment

… floor

Row sets that compress very well could be under 1 MiB on the wire but
much larger decompressed, so they stayed on the heap and kept the
retention. Start such streams on the heap and move them to a map once
the bytes written reach the floor (copying the < 1 MiB written so far).
Every map still holds at least 1 MiB of stream data.

Signed-off-by: Vu Anh Phung <[email protected]>
Co-authored-by: Isaac <[email protected]>

peco-review-bot Bot left a comment