From: | Guillaume Smet <guillaume_ml(at)smet(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | josh(at)agliodbs(dot)com, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Bad plan after vacuum analyze |
Date: | 2005-05-11 19:32:11 |
Message-ID: | 42825DBB.7000703@smet.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom,
> So, the usual questions: have these two tables been ANALYZEd lately?
Yes, of course.
As I wrote in my previous mail, here is how I reproduce the problem:
- we load the dump in a new database (to be sure, there is no problem on
an index or something like that)
- query: it's fast (< 1ms)
- *VACUUM FULL ANALYZE;*
- query: it's really slow (130ms) and it's another plan
- set enable_seqscan=off;
- query: it's fast (< 1ms) : it uses the best plan
I reproduced it on two different servers exactly like that (7.4.5 and
7.4.7).
I first met the problem on a production database with a VACUUM ANALYZE
run every night (and we don't have too many inserts a day on this database).
> If so, can we see the pg_stats rows for the object_id and
> parent_application_id columns?
See attached file.
If you're interested in a dump of these tables, just tell me. There
aren't any confidential information in them.
Regards
--
Guillaume
Attachment | Content-Type | Size |
---|---|---|
stats.txt | text/plain | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-05-11 19:38:16 | Re: Bad plan after vacuum analyze |
Previous Message | Mischa Sandberg | 2005-05-11 19:06:56 | Re: Prefetch |