| 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 |
| 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 |