Re: Parallel vacuum: workers together with leader could overrun cost budget

Hi Bharath,

Thank you for the patches.

I ran v2 on master for 1M rows, 8 indexes, 10% deleted, cost delay 10ms /
limit 1000, so a budget of about 100k units/s. Each run
did roughly the same work (~650k units, estimated from VERBOSE buffer
counts):

PARALLEL master v2
0 82k/s 7.9s 82k/s 8.0s
2 152k/s 4.3s 90k/s 7.2s
8 (7) 243k/s 2.7s 97k/s 6.7s

So master runs at up to ~2.4x the budget, and v2 stays under it, including
with more than 4 processes. The vacuum and vacuum_parallel
regression output matches expected.

Regarding the 1s cap, I think the 800 in your example is where the 6.4s
cap kicks in, not the 1s one. With delay 100ms, limit 200 and 16 processes,
the 1s cap applies once the local balance passes 125,
which can probably happen just from uneven work across processes, no
skipped delay points needed. It's bounded though, a capped process
gets at most roughly 1.6-1.8x its share there, and only once nworkers *
cost_delay gets near 1s. So I'm fine with the 1s cap, but
I'd mention that in the comment instead of saying the budget always holds.

Regarding the WaitLatch() for HEAD, worth remembering it was tried before
(4753ef37e0e) and reverted in 720de00af49 because the millisecond timeout
broke fractional cost_delay.

One thing I'm less sure about is back-patching to 14-18. Plain manual
VACUUM already goes parallel when there are enough indexes, so anyone
with a cost delay set could see it get noticeably slower after a minor
update (with the default 2 workers, 4.3s -> 7.2s above).
Fixing it in 19 and master seems safer to me, but I'm happy to go with the
consensus.

Thanks,
Surya Poondla