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

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: Raw Message | Whole Thread | 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?

In response to

Responses

Browse pgsql-hackers by date

  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