On Sat, 25 May 2002 14:21:52 -0400, Tom Lane <[EMAIL PROTECTED]> 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 (?) ... Servus Manfred ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
