Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
> > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> >>
> >> 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                      
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to