On Sat, 25 May 2002 14:21:52 -0400, Tom Lane <tgl@sss.pgh.pa.us>
wrote:
>I'm somewhat concerned that the more stringent locking will slow down
>VACUUM a good deal when there's lots of concurrent activity, but I don't
>see another answer. Ideas anyone?
Ideas? Always! :-) Don't know if this one is so bright, but at least
we have something to vote on:
On leaf pages order index tuples by heap item pointer, if otherwise
equal. In IndexScanDescData remember the whole index tuple (including
the heap item pointer) instead of ItemPointerData. Then depending on
scan direction _bt_next() would look for the first index tuple greater
or less than currentItem respectively.
Implications:
(+) higher concurrency: normal write locks
(+) robust: can always start from the root, if nothing else helps
(though I can't think of a case making this necesary)
(-) need heap item pointer in internal nodes (could partly be
compensated by omitting unused(?) t_tid.ip_posid)
(+) btinsert knows, where to insert a new tuple, even if there are
lots of duplicates (no random())
(-) this could result in more half-empty leaf pages?
(+) dead index tuples can be removed on the fly
(?) ...
ServusManfred