Re: Keep TIDBitmap pagetable memory across bitmap scans

From: Greg Burd <greg(at)burd(dot)me>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: David Geier <geidav(dot)pg(at)gmail(dot)com>, John Naylor <johncnaylorls(at)gmail(dot)com>
Subject: Re: Keep TIDBitmap pagetable memory across bitmap scans
Date: 2026-11-13 19:45:53
Message-ID: avdou1CoTYOUeRaV@werk
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

v2 attached, rebased on master (ef1b740441c). 0002 is unchanged; two
fixes in 0001's test:

- cfbot's 32-bit Linux job failed test_tidbitmap [1]. One query returned
the number of lossy pages for three bitmaps with a 1 MB limit, and that
number depends on the pointer size: tbm_calculate_entries() counts two
pointers per entry for the iteration arrays, so 1 MB allows 16,384
entries with 8-byte pointers and 18,724 with 4-byte ones, and fewer
pages go lossy. 16,514 became 18,874 on i386, which I reproduced with
an i386 build. The test now checks only that some pages went lossy, as
its neighbours already do.

- The cancel case printed a CONTEXT line that depends on where the
statement timeout fires, inside pg_sleep or not. It failed once in my
runs; it now runs with VERBOSITY terse.

The direction is still the open question from my last mail: whether to
fix this per allocation site, as 0002 does for the TIDBitmap, or once
for the whole process, since hash join and sort fault the same way. I'm
keeping the patch current while that's discussed.

best.

-greg

[1] https://github.com/postgres/postgres-cfbot/actions/runs/42661536023/job/129314681459

Attachment Content-Type Size
v2-0002-Keep-TIDBitmap-pagetable-memory-for-the-next-bitm.patch.gz application/gzip 6.5 KB
v2-0001-Add-test-module-for-TIDBitmap.patch.gz application/gzip 7.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xiaoxuan Li 2026-11-13 20:06:28 Re: Adding a stored generated column without long-lived locks
Previous Message Manu 2026-11-13 19:45:23 Re: Dropping a composite attribute causes data integrity violations