Re: Improving scalability of Parallel Bitmap Heap/Index Scan

On Wed, Oct 14, 2026 at 5:27 AM David Geier <geidav(dot)pg(at)gmail(dot)com> wrote:
> > If that's the case, let's get that piece in committable shape first.
> > That will make sure PG20 gets some improvement regardless of what
> > happens with your other proposal, and allows us to isolate the effect
> > of the proposed architectural change.
> Attached is the patch for using sort_template.h in TIDBitmap based on
> master. No other parallel BIS changes.

+/* Needed for sort template to work with pointers to PagetableEntry */
+typedef PagetableEntry *PagetableEntryPtr;

This is a workaround; let's fix it properly, like this:

ST_POINTER_TYPE *a = (ST_POINTER_TYPE *) data;
ST_POINTER_TYPE *pa;
ST_POINTER_TYPE *pb;
...

I see that Thomas already encountered that problem in the 0001 patch
of that series:

https://www.postgresql.org/message-id/attachment/120554/0001-Add-bsearch-and-unique-templates-to-sort_template.h.patch

+#define ST_COMPARE(a, b) pg_cmp_u32((*(a))->blockno, (*(b))->blockno)
...
+#define ST_COMPARE(a, b, base) pg_cmp_u32(base[*(a)].blockno,
base[*(b)].blockno)

There's a comment in common/int.h that says:

* NB: If the comparator function is inlined, some compilers may produce
* worse code with these helper functions than with code with the
* following form:
*
* if (a < b)
* return -1;
* if (a > b)
* return 1;
* return 0;

...and that's been true every time it's tried. It should be fine to
instead make the current comparators static inline and make both match
the above pattern. You might get a further speed-up.

--
John Naylor
Amazon Web Services