Horton

Re: BitmapHeapScan streaming read user and prelim refactoring

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Tomas Vondra <tomas@vondra.me>, Nazir Bilal Yavuz <byavuz81@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Andres Freund <andres@anarazel.de>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2025-02-13T22:50:29Z
Lists: pgsql-hackers 
On Fri, Feb 14, 2025 at 5:52 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> On Thu, Feb 13, 2025 at 11:28 AM Tomas Vondra <tomas@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.

Commits

  1. Fix bitmapheapscan incorrect recheck of NULL tuples

  2. Increase default maintenance_io_concurrency to 16

  3. Separate TBM[Shared|Private]Iterator and TBMIterateResult

  4. Improve read_stream.c advice for dense streams.

  5. Increase default effective_io_concurrency to 16

  6. Delay extraction of TIDBitmap per page offsets

  7. Add lossy indicator to TBMIterateResult

  8. Move BitmapTableScan per-scan setup into a helper

  9. Add and use BitmapHeapScanDescData struct

  10. Fix bitmap table scan crash on iterator release

  11. Bitmap Table Scans use unified TBMIterator

  12. Add common interface for TBMIterators

  13. Make table_scan_bitmap_next_block() async-friendly

  14. Move EXPLAIN counter increment to heapam_scan_bitmap_next_block

  15. Refactor tidstore.c iterator buffering.

  16. BitmapHeapScan: Remove incorrect assert and reset field

  17. Change BitmapAdjustPrefetchIterator to accept BlockNumber

  18. BitmapHeapScan: Use correct recheck flag for skip_fetch

  19. BitmapHeapScan: Push skip_fetch optimization into table AM

  20. BitmapHeapScan: postpone setting can_skip_fetch

  21. BitmapHeapScan: begin scan after bitmap creation

  22. Fix EXPLAIN Bitmap heap scan to count pages with no visible tuples

  23. Remove redundant snapshot copying from parallel leader to workers

  24. Remove some obsolete smgrcloseall() calls.

  25. Remove the "snapshot too old" feature.

  26. Compute XID horizon for page level index vacuum on primary.