Re: Page at a time index scan

Heikki Linnakangas <hlinnaka@iki.fi> 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