Robert Haas napsal(a):
Really, what I'd ideally like to see here is a system where the V3
code is in essence error-recovery code. Everything should be V4-only
unless you detect a V3 page, and then you error out (if in-place
upgrade is not enabled) or jump to the appropriate V3-aware code (if
in-place upgrade is enabled). In theory, with a system like this, it
seems like the overhead for V4 ought to be no more than the cost of
checking the page version on each page read, which is a cheap sanity
check we'd be willing to pay for anyway, and trivial in cost.
OK. It was original idea to make "Convert on read" which has several problems
with no easy solution. One is that new data does not fit on the page and second
big problem is how to convert TOAST table data. Another problem which is general
is how to convert indexes...
Convert on read has minimal impact on core when latest version is processed. But
problem is what happen when you need to migrate tuple form page to new one
modify index and also needs convert toast value(s)... Problem is that response
could be long in some query, because it invokes a lot of changes and conversion.
I think in corner case it could requires converts all index when you request
one record.
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
