Decibel! napsal(a):
Unless I'm mistaken, there are only two cases we care about for
additional space: per-page and per-tuple.
Yes. And maybe special space indexes could be extended, but it is covered in
per-page setting.
Those requirements could also
vary for different types of pg_class objects. What we need is an API
that allows an administrator to tell the database to start setting this
space aside. One possibility:
We need API or mechanism how in-place upgrade will setup it. It must be done by
in-place upgrade.
<snip>
relkind: Essentially, heap vs toast, though I suppose it's possible we
might need this for sequences.
Sequences are converted during catalog upgrade.
<snip>
Once we have an API, we need to get users to make use of it. I'm
thinking add something like the following to the release notes:
"To upgrade from a prior version to 8.4, you will need to run some of
the following commands, depending on what version you are currently using:
<snip>
It is too complicated. At first it depends also on architecture and it is
possible to easily compute by in-place upgrade script. What you need is only run
script which do all setting for you. You can obtain it from next version (IIRC
Oracle do it this way) or we can add this configuration script into previous
version during a minor update.
OTOH, we might not want to go mucking around with changing the catalog
for older versions (I'm not even sure if we can). So perhaps it would be
better to store this information in a separate table, or maybe a
separate file. That might be best anyway; we generally wouldn't need
this information, so it would be nice if it wasn't bloating pg_class all
the time.
It is why I selected relopt for storing this configuration parameter, which is
supported from 8.2 and upgrade from 8.1->8.2 works fine.
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
