> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > I know I have expressed these concerns before but lost the argument,
>
> Yes, you did, and it's way too late to bring them up again.
> Particularly the OID issue; do you seriously propose an initdb
> at this stage to put back OIDs in the system tables?
No, I don't expect any changes. I just felt I needed to clearly state
my opinion on this so people know where we are headed.
> But for the record:
>
> I think your argument about VACUUM misses the point. The reason FULL
> isn't the default is that we want the default form to be the one people
> most want to use. If lightweight VACUUM starts to be run automatically
> in some future release, FULL might at that time become the default.
> I don't see anything wrong with changing the default behavior of the
> command whenever the system's other behavior changes enough to alter the
> "typical" usage of the command.
Agreed. VACUUM nolock will be the most used method of vacuum for 7.2.
My concern was that FULL is still needed sometimes _and_ may become the
more popular vacuum method in later releases as vacuum nolock becomes
automatic.
Vacuum may go from locking (7.1), to non-locking (7.2), to locking (7.3)
in the span of three releases. My point was that keeping vacuum as
locking in all releases and adding a non-locking version only for 7.2
seemed cleaner.
Now, if you think we will continue needing a non-locking vacuum in all
future releases then we are doing the right thing by making non-locking
the default. Is that true?
> As for pg_description, the change in primary key is unfortunate but
> *necessary*. I don't foresee us reversing it. The consensus view as
> I recall it was that we wanted to go over to a separate OID generator
> per table in some future release, which fits right in with the new
> structure of pg_description, but is entirely unworkable with the old.
In other words, a separate sequence for each system table, right? Is
that where we are headed? We could still call the column oid and
queries would continue to work. I don't think there are many
cases where the oid is used to find a particular table, except my
/contrib/findoidjoins, which can be removed.
-- 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
