Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Also, could we calculate a better estimate of the maximum number of > offsets an index page can hold?
We could make something analogous to MaxHeapTuplesPerPage --- the correct number ought to be approximately BLCKSZ/16 I should think. (It's not possible for an entry to be *just* the header, there has to be either a datum or a null bitmap. Hence, with maxalign padding, at least 12 bytes for item, plus 4 for item pointer.) > Now that I look at it: Why do we have a separate vacuum_cleanup function > at all? Calls to index_vacuum_cleanup go hand in hand with calls to > index_bulk_delete. Yeah, I was just thinking we ought to revisit that. The original idea was that vacuumcleanup would be called just once at the end of vacuuming, not once per bulkdelete. I don't recall why I changed it but it was probably a bad idea to do so. >> Agreed. The pin has two functions: >> - keep the page from being moved out of the bufmgr - no need anymore >> - stop a vacuum from removing the page - no need anymore. We'll not stop >> on a removable row anymore, so no need. > At the moment, backward scan returns to the page to walk left from there. Backwards scan may break this whole concept; are you sure you've thought it through? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly