From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | scrappy(at)hub(dot)org (The Hermit Hacker) |
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 19:40:03 |
Message-ID: | 199802031940.OAA25843@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> 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.
--
Bruce Momjian
maillist(at)candle(dot)pha(dot)pa(dot)us
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 1998-02-03 19:42:18 | Re: [HACKERS] Re: [QUESTIONS] MySQL benchmark page |
Previous Message | The Hermit Hacker | 1998-02-03 19:30:57 | Re: [HACKERS] Re: [QUESTIONS] MySQL benchmark page |