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
