Bruce Momjian napsal(a):
As far as the page not fitting after conversion, what about some user
command that will convert an entire table to the new format if page
expansion fails.
Keep in a mind that there are more kind of pages. Heap is easy, but each index
AM has own specific :(. Better approach is move tuple to the new page and
invalidate all related table indexes. Following reindex automatically convert
whole table.
After putting all those together, how large a patch are we talking
about, and what's the performance penalty then? How much of all that
needs to be in core, and how much can live in a pgfoundry project or an
extra binary in src/bin or contrib? I realize that none of us have a
crystal ball, and one has to start somewhere, but I feel uneasy
committing to an approach until we have a full plan.
Yes, another very good point.
I am ready to focus on these issues for 8.4; all this needs to be
fleshed out, perhaps on a wiki. As a starting point, what would be
really nice is to start a wiki that lists all data format changes for
every major release.
As Greg mentioned in his mail there wiki page is already there. Unfortunately, I
did not time to put actual information there. I'm going to do soon.
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
