Re: [HACKERS] Some notes on optimizer cost estimates

On Thu, 20 Jan 2000, Bruce Momjian wrote:

> > "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.

Hrmmm...how about making ANALYZE a seperate function, while a VACUUM does
an ANALYZE implicitly?

Then again, whatever happened with the work that was being done to make
VACUUM either non-locking *or*, at least, lock only the table being
vacuum'd?

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org