On Tue, Oct 11, 2011 at 4:21 PM, Kääriäinen Anssi <anssi.kaariai...@thl.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
