"Robert Haas" <[EMAIL PROTECTED]> writes:
> To spell this out in more detail:
> Suppose page 123 is a V3 page containing 6 tuples A, B, C, D, E, and
> F. We examine the page and determine that if we convert this to a V4
> page, only five tuples will fit. So we need to get rid of one of the
> tuples. We begin a transaction and choose F as the victim. Searching
> the FSM, we discover that page 456 is a V4 page with available free
> space. We pin and lock pages 123 and 456 just as if we were doing a
> heap_update. We create F', the V4 version of F, and write it onto
> page 456. We set xmax on the original F. We peform the corresponding
> index updates and commit the transaction.
> Time passes. Eventually F becomes dead. We reclaim the space
> previously used by F, and page 123 now contains only 5 tuples. This
> is exactly what we needed in order to convert page F to a V4 page, so
> we do.
That's all fine and dandy, except that it presumes that you can perform
SELECT/UPDATE/DELETE on V3 tuple versions; you can't just pretend that
A-E aren't there until they get converted. Which is exactly the
overhead we were looking to avoid.
(Another small issue is exactly when you convert the index entries,
should you be faced with an upgrade that requires that.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
