Re: Concerns about this release

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

In response to

Responses

Browse pgsql-hackers by date

  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