Tom Lane napsal(a):
"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.
We want to avoid overhead on V$lastest$ tuples, but I guess small performance
gap on old tuple is acceptable. The only way (which I see now) how it should
work is to have multi page version processing. And old tuple will be converted
when PageGetHepaTuple will be called.
However, how Heikki mentioned tuple and page conversion is basic and same for
all upgrade method and it should be done first.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
