| 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: | Whole Thread | Raw Message | 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 |