Gregory Stark wrote: > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > Stefan Kaltenbrunner <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
