Robert Haas napsal(a):
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.
I don't think I'm proposing convert on read, exactly. If you actually
try to convert the entire page when you read it in, I think you're
doomed to failure, because, as you rightly point out, there is
absolutely no guarantee that the page contents in their new format
will still fit into one block. I think what you want to do is convert
the structures within the page one by one as you read them out of the
page. The proposed refactoring of ExecStoreTuple will do exactly
this, for example.
I see. But Vacuum and other internals function access heap pages directly
without ExecStoreTuple. however you point to one idea which I'm currently
thinking about it too. There is my version:
If you look into new page API it has PageGetHeapTuple. It could do the
conversion job. Problem is that you don't have relation info there and you
cannot convert data, but transaction information can be converted.
I think about HeapTupleData structure modification. It will have pointer to
transaction info t_transinfo, which will point to the page tuple for V4. For V3
PageGetHeapTuple function will allocate memory and put converted data here.
ExecStoreTuple will finally convert data. Because it know about relation and It
does not make sense convert data early. Who wants to convert invisible or dead data.
With this approach tuple will be processed same way with V4 without any overhead
(they will be small overhead with allocating and free heaptupledata in some
places - mostly vacuum).
Only multi version access will be driven on page basis.
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
