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

>
> On Tue, 3 Feb 1998, Bruce Momjian wrote:
>
> > >
> > > On Tue, 3 Feb 1998, Bruce Momjian wrote:
> > >
> > > > > > This is correct.  Vacuum is fast, vacuum analyze is pretty slow.  We
> > > > > > could separate them, I guess, and that would eliminate the write-lock
> > > > > > and be only a readlock.
> > > > >
> > > > >     Possible to slip it in for v6.3?  Would make it so that an analyze
> > > > > could be done nightly, to keep statistics up, and then a vacuum once a
> > > > > week or so just for garbage collection...?
> > > >
> > > > When I added analyze, I did not understand the issues, so I was able to
> > > > work from Vadim's code in vacuum.  I put it on the TODO list.  Don't
> > > > know if it can make 6.3.  I am working on cleaning up the cacheoffset
> > > > code right now.
> > >
> > >     Okay...personally, I'm finding 'vacuum <table>' an acceptable work
> > > around, so it isn't too big of a priority :)
> > >
> >
> > Vacuum probably write-locks the pg_class table because it updates the
> > table statistics.  By vacuuming one table at a time, your lock is
> > removed and re-asserted, allowing other people to get into pg_class, and
> > a scan of pg_class is not necessary becuase you supply the table names.
>
>     Wait, then I think I got this backwards.
>
>     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.

--
Bruce Momjian
maillist@candle.pha.pa.us