On Mon, Jun 16, 2025 at 9:58 PM Melanie Plageman <melanieplage...@gmail.com> wrote: > > Test in attached patch seems to do the job on 32 bit and 64 bit when tested.
Great! +log_recovery_conflict_waits = true I don't see this on pg16 -- If this is good to have, maybe worth calling out in the commit message as a difference? +# The TIDStore which vacuum uses to store dead items is optimized for its +# target system. On a 32-bit system, our example requires around 9000 rows to +# have enough dead items spread out across enough pages to fill the TIDStore +# and trigger a second round of index vacuuming. We could get away with fewer +# rows on 64-bit systems, but it doesn't seem worth the special case. Minor quibble: I wouldn't say it is deliberately optimized (at least not on local memory) -- it's more of a consequence of pointer-sizes and the somewhat arbitrary choice to set the slab block sizes to hold about X number of chunks. For v19, it might be good to hard-code the block sizes to reduce the possibility of difference and allow a smaller table. +my $nrows = 9000; Running the queries in isolation on an -m32 build shows running 5 index scans, and I found 4000 runs 3 index scans both with and without asserts. Of course, I'm only using the normal 8kB block sizes. In any case, 9000 is already a lot less than 200000, so we can go with that for v17 and v18. -- John Naylor Amazon Web Services
