Re: [HACKERS] Re: [QUESTIONS] MySQL benchmark page

Marc G. Fournier <scrappy@hub.org>

From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
Cc: herouth@oumail.openu.ac.il, pgsql-hackers@postgreSQL.org
Date: 1998-02-03T20:02:00Z
Lists: pgsql-hackers
On Tue, 3 Feb 1998, Bruce Momjian wrote:

> > 	Vacuum right now locks pg_class because of the statistics?  If
> > that is the case, if we made vacuum *just* garbage collecting,it wouldn't
> > have to lock pg_class, only "vacuum analyze" wouldhave to do that?
> > 
> > 	So, I was misunderstanding in that I was thinking that 'vacuum
> > analyze' only needed the read-lock :(
> 
> Maybe I am wrong.  I have not looked at it.

	Okay, just sitting here thinking about it, and that doesn't really
make sense (if its true)...

	Vacuum should be locking the table itself for a garbage cleanup,
since it has to move around records, and I wouldn't imagine you'd want to
have someone doing a SELECT at the same time.  So, that locks the *table*
itself, but shouldn't affect pg_class (statistically)

	Once the vacuum is finished its garbage cleanup phase (which,
granted, could take several minutes), then the statistics phase would come
into play...but again, a lock on pg_class shouldn't have to be imposed
until the 'update' of the table takes place, should it?  

	So, why is pg_class locked for the duration of a vacuum when the
vacuum is being performed for the whole database when it should (I think)
only need to be locked when updates are happening to it?