Re: [HACKERS] Re: [QUESTIONS] MySQL benchmark page
От | The Hermit Hacker |
---|---|
Тема | Re: [HACKERS] Re: [QUESTIONS] MySQL benchmark page |
Дата | |
Msg-id | Pine.NEB.3.95.980203144712.14960o-100000@hub.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: [QUESTIONS] MySQL benchmark page (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | 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?
В списке pgsql-hackers по дате отправления: