From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Concerns about this release |
Date: | 2001-12-18 21:02:22 |
Message-ID: | 200112182102.fBIL2Mn08593@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2001-12-18 21:03:30 | Re: Connection Pooling, a year later |
Previous Message | Don Baccus | 2001-12-18 21:01:09 | Re: Connection Pooling, a year later |