I know I have expressed these concerns before but lost the argument, or
at least no one rallied to my position, but I feel I have to mention
these again because they came up during beta.
My first concern is that VACUUM now defaults to the non-locking version.
While I appreciate the new non-locking code, I imagine a release where
non-locking VACUUM will happen automatically, making no need to run
VACUUM. However, locking VACUUM will still need to be run by
administrators, so we may be left with a VACUUM no one needs to run but
a VACUUM FULL that does need to be run, leaving us with a useless
default for VACUUM without the FULL keyword. Also, because VACUUM does
not store the freetuple list between postmaster restarts, nor does it
have any way of recording _all_ free tuples, it has to be run with a
different frequency than the old VACUUM that I assume most people ran at
night. I would have preferred to leave VACUUM as locking VACUUM and
create a new lighter option to the VACUUM command, and if light vacuum
later becomes automatic, the option can just go away.
Second, I am concerned about the removal of oids from system tables. I
realize this was done to prevent oid usage, particularly by the creation
of temp tables, but such savings only make sense when oids are turned
off in postgresql.conf. I imagine future releases where we have a
separate oid counter for system/user tables, or 8-bytes oids, in which
case the removal of oids from system tables may be needless. We have
seen OpenACS is broken now because the new pg_description requires a
separate classoid/objsubid columns to uniquely access tables without
oids, like pg_attribute. These new columns are used only for non-oid
tables, making access cumbersome, rather than the simpler oid lookup. I
don't even know if the current setup will allow other tables without
oids to be referenced cleanly. Object dependency tracking, using
pg_depend, will also require these additional fields to track
dependency, rather than just using the oid, and such access will be more
confusing.
I realize the motivation for these changes were to make PostgreSQL more
enterprise-ready, but I am concerned these changes may need to be
modified in future releases, causing confusion and porting problems for
users.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026