On Fri, Feb 14, 2025 at 5:52 AM Melanie Plageman <melanieplage...@gmail.com> wrote: > On Thu, Feb 13, 2025 at 11:28 AM Tomas Vondra <to...@vondra.me> wrote: > > On 2/13/25 17:01, Melanie Plageman wrote: > > I know it's not changing how much memory we allocate (compared to > > master). I haven't thought about the GinScanEntry - yes, flexible array > > member would make this a bit more complex. > > Oh, I see. I didn't understand Thomas' proposal. I don't know how hard > it would be to make tidbitmap allocate the offsets on-demand. I'd need > to investigate more. But probably not worth it for this patch.
No, what I meant was: It would be nice to try to hold only one uncompressed result set in memory at a time, like we achieved in the vacuum patches. The consumer expands them from a tiny object when the associated buffer pops out the other end. That should be possible here too, right, because the bitmap is immutable and long lived, so you should be able to stream (essentially) pointers into its internal guts. The current patch streams the uncompressed data itself, and thus has to reserve space for the maximum possible amount of it, and also forces you to think about fixed sizes. I think if you want "consumer does the expanding" and also "dynamic size" and also "consumer provides memory to avoid palloc churn", then you might need two new functions: "how much memory would I need to expand this thing?" and a "please expand it right here, it has the amount of space you told me!". Then I guess the consumer could keep recycling the same piece of memory, and repalloc() if it's not big enough. Or something like that. Yeah I guess you could in theory also stream pointers to individual uncompressed result objects allocated with palloc(), that is point a point in the per-buffer-data and make the consumer free it, but that has other problems (less locality, allocator churn, need cleanup/destructor mechanism for when the streams is reset or destroyed early, still has lots of uncompressed copies of data in memory *sometimes*) and is not what I was imagining.
