| From: | The Hermit Hacker <scrappy(at)hub(dot)org> |
|---|---|
| To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | herouth(at)oumail(dot)openu(dot)ac(dot)il, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] Re: [QUESTIONS] MySQL benchmark page |
| Date: | 1998-02-03 20:02:00 |
| Message-ID: | Pine.NEB.3.95.980203144712.14960o-100000@hub.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | James Hughes | 1998-02-03 20:36:46 | Re: [HACKERS] VACUUM ANALYZE Problem |
| Previous Message | Bruce Momjian | 1998-02-03 19:57:46 | PL code and fmgr_addr |