Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

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                        |
  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


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-12-18 21:03:30
Subject: Re: Connection Pooling, a year later
Previous:From: Don BaccusDate: 2001-12-18 21:01:09
Subject: Re: Connection Pooling, a year later

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group