RE: [HACKERS] Some notes on optimizer cost estimates
От | Hiroshi Inoue |
---|---|
Тема | RE: [HACKERS] Some notes on optimizer cost estimates |
Дата | |
Msg-id | 001301bf63bd$95cbe680$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Some notes on optimizer cost estimates (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > > "Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > > > I've wondered why we cound't analyze database without vacuum. > > > We couldn't run vacuum light-heartedly because it acquires an > > > exclusive lock for the target table. > > > > There is probably no real good reason, except backwards compatibility, > > why the ANALYZE function (obtaining pg_statistic data) is part of > > VACUUM at all --- it could just as easily be a separate command that > > would only use read access on the database. Bruce is thinking about > > restructuring VACUUM, so maybe now is a good time to think about > > splitting out the ANALYZE code too. > > I put it in vacuum because at the time I didn't know how to do such > things and vacuum already scanned the table. I just linked on the the > scan. Seemed like a good idea at the time. > > It is nice that ANALYZE is done during vacuum. I can't imagine why you > would want to do an analyze without adding a vacuum to it. I guess > that's why I made them the same command. > > If I made them separate commands, both would have to scan the table, > though the analyze could do it without the exclusive lock, which would > be good. > The functionality of VACUUM and ANALYZE is quite different. I don't prefer to charge VACUUM more than now about analyzing database. Probably looong lock,more aborts .... Various kind of analysis would be possible by splitting out ANALYZE. Regards. Hiroshi Inoue Inoue@tpf.co.jp
В списке pgsql-hackers по дате отправления: