Re: [PATCH v1] Batch B-tree TIDs when building a bitmap

On Fri, Oct 9, 2026 at 2:12 AM David Geier <geidav(dot)pg(at)gmail(dot)com> wrote:
>
> > The same optimization can be applied, by the way, to at least the GIST,
> > the GIN and the HASH index implementations. I'll do that the next days
> > when I find some time.
> Done for B-tree, hash, GiST, GIN, SP-GiST, and bloom indexes.
> Attached patch passes tests.
>
> Also created a commit fest entry:
> https://commitfest.postgresql.org/patch/7422/
>
> --
> David Geier

Hi David,

I reviewed v2 and also looked back at my local benchmark results for
the B-tree batching path.

The commit message now explains the two relevant effects well: reuse
of the current TIDBitmap page entry and amortization of per-call
overhead.

One B-tree implementation detail still seems worth changing. The copy
loop updates so->currPos.itemIndex for every TID. Using a local index
and updating itemIndex once after the copy improved the 10M-row
workload by another 2.24% in my tests. The new hash code uses the same
pattern and could use the same cleanup.

I also measured a small regression for a B-tree scan returning ten
widely spaced keys:

baseline: 33.195 us
patched: 33.569 us
delta: +0.85%

I do not consider that a blocker, but it shows that copying into a
batch is not free for tiny sparse scans.

The main new aspect of v2 is that batching is now applied to hash,
GiST, GIN, SP-GiST, and bloom as well. I do not see an obvious
semantic problem with separating exact and recheck batches, since the
TIDBitmap recheck flag is maintained at page level.

However, my measurements demonstrate the benefit for B-tree, not
necessarily for all of the newly covered access methods. Their result
ordering and heap-page locality can be quite different. I think those
additions need targeted measurements, or could be split into follow-up
patches.

A couple of smaller points:

gistScanPage() allocates both page-sized arrays even for non-bitmap
scans.
The SP-GiST buffers enlarge every scan opaque, including tuple scans.
A comment explaining the B-tree primitive-scan loop and the
BTScanPosItem copy would help.
There are a few pgindent and 80-column issues in the new code.

The B-tree batching approach still looks worthwhile to me. I would
apply the local-index cleanup there, but I would want some performance
evidence for the newly added access methods before treating the whole
v2 patch as ready.

Thanks,
Haibo