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
requiresconverts all index when you request
one record.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
