Hannu Krosing wrote:
Ühel kenal päeval, P, 2007-02-11 kell 12:35, kirjutas Tom Lane:
Hannu Krosing <[EMAIL PROTECTED]> writes:
What if we would just reuse the root tuple directly instead of turning
it into a stub ?
This would create a cycle of ctid pointers, which changes the lookup
process from 'follow ctid chaint until the end' to 'follow the tid chain
until you reach the start'.
How do you know which one is newest?
By xmin,cmin of course .
What happens when you have to put a newer version off-page for lack of space?
Then this scheme won't work.
Couldn't the ctid of the latest tuple point to the off-page tuple as usual?
As long as the index points to any tuple in the update chain, an index
scan can even scan the whole page to find all the earlier tuples in the
chain. The latest version can always be found by following the c_tid
pointers, so that would only be needed to find an older version of the row.
How about adding a new 2-byte field to header for in-page c_tid poiner
for HOT ?
It grows header from 26 to 28 bytes, but for MAXALIGN=4 the space usage
would stay the same.
Actually the tuple header is now 23 bytes, thanks to combo (aka phantom)
cids. Adding a new 2-byte field would take it over 24 bytes again,
making it either 28 or 32 bytes depending on MAXALIGN.
It might be acceptable, if it was only stored on those tuples that are
(HOT) updated. But it's not clear to me what you're proposing to do with
the field, anyway, Which tuples would have it, and what would it point to?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
