From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Page at a time index scan |
Date: | 2006-05-02 16:04:21 |
Message-ID: | 8949.1146585861@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Heikki Linnakangas <hlinnaka(at)iki(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Brant | 2006-05-02 16:29:44 | Re: pgstat: remove delayed destroy / pipe: |
Previous Message | Heikki Linnakangas | 2006-05-02 15:40:45 | Re: Page at a time index scan |