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