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?