Tom Lane napsal(a):
> "Robert Haas" <robertmhaas@gmail.com> 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