Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
> > Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> >> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lionfish&dt=2007-07-24%2005:30:13
> >> any ideas ?
> >
> > I saw what I think was the identical failure last night on my own
> > machine, but it wasn't repeatable. Evidently the planner is changing to
> > a different plan for those queries, but why has this only started
> > recently? Maybe the recent changes to autovacuum defaults are causing
> > autovac to hit these tables when it never did before?
That's quite possible, because the change in threshold means it will hit
small tables earlier than it used to do.
> This does raise a possible issue with autovacuum. Treating ANALYZE like VACUUM
> and running it on individual tables one at a time is probably the wrong thing
> to be doing. What really has to happen is it should run analyze on all tables
> together in a single transaction and commit all the new stats together.
> Out-of-sync stats can be worse than out-of-date stats.
One problem with that is that it will keep the locks on each table until
the end of all analyzes.
What I don't understand is what you mean with it "obliterating" the
stats for a table. I mean, when analyze runs, it _updates_ the stats
for the table, so there's never a time when the table does not have any
stats (unless, of course, analyze has never been run on the table).
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.