Heikki Linnakangas <hlinnaka@iki.fi> writes:
> That's not too bad. Where exactly were you thinking of putting the
> counter and the lock?
My original thought was to keep it in btree metapages, but that's kind
of annoying since we just went to some effort to cache metapage
contents; which means the metapage will likely not be hanging around in
buffer cache. Right now I'm thinking we could have a single system-wide
counter instead of one per index, and keep it in shared memory. There's
no strong reason why it needs to survive system crash/restart AFAICS.
Aside from the counter proper, shared memory would need to contain
enough info so we could tell whether btbulkdelete was active for any
particular index, and the marker value to use for that index if so.
But this requires only enough space for 1 entry per active vacuum,
which is bounded by MaxBackends and will usually be a lot smaller.
A benefit of doing it that way is that when btbulkdelete isn't active,
splits can reliably tell so and write zero into the page markers.
That reduces the odds of false positives quite a lot, assuming that
bulkdelete is only active a small fraction of the time.
BTW, I'm currently working on cleaning up the page-at-a-time-scan
part of your patch, since we could apply that without changing
VACUUM at all. We need to do performance testing on that and make
sure it won't kill us for unique indexes, else this whole project
may have to be shelved :-(. I've found a few more problems, eg the
code doesn't handle changes in indexscan direction properly, but
no showstoppers.
regards, tom lane