RE: [HACKERS] Some notes on optimizer cost estimates

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)us]
>
> > "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)tpf(dot)co(dot)jp