Re: Index only scan paving the way for "auto" clustered tables?

On Tue, Oct 11, 2011 at 4:21 PM, Kääriäinen Anssi
<anssi(dot)kaariainen(at)thl(dot)fi> wrote:
> This is probably a silly idea, but I have been wondering about the
> following idea: Instead of having visibility info in the row header,
> have a couple of row visibility slots in the page header. These slots
> could be shared between rows in the page, so that if you do a bulk
> insert/update/delete you would only use one slot. If the slots
> overflow, you would use external slots buffer.
>
> When the row is all visible, no slot would be used at all.

I've thought about stuff like this, too. One idea would be to make
the slots just be items on the page. Each tuple includes a 2-byte
field which points to the item number (on the same page) where the
XMAX, CID, and CTID information for the update/delete of that tuple is
stored. If the tuple isn't updated or deleted, it points back to the
tuple's own item ID. When a tuple is updated or deleted, add an item
to the page with the necessary XMAX/CMAX/CTID and set the pointer to
the new item ID. If the page is full, allocate an "overflow block"
and store the overflow block number in the page header. Add the new
item to the overflow block and set the 2-byte field to point to it,
setting the high bit or something like that to indicate that the data
is in the overflow block rather than the data block. The main
objection to this idea I see is that if the overflow blocks get much
use, the overall performance might end up being poor.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company