| 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:57:02 |
| Message-ID: | 4282638E.2020307@smet.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> Well, those stats certainly appear to justify the planner's belief that
> the indexscan needn't run very far: the one value of
> parent_application_id is 1031 and this is below the smallest value of
> object_id seen by analyze.
Yes, it seems rather logical but why does it cost so much if it should
be an effective way to find the row?
> You might have better luck if you increase
> the statistics target for acs_objects.object_id.
What do you mean exactly?
> (It'd be interesting
> to know what fraction of acs_objects actually does have object_id <
1032.)
ccm_perf=# SELECT COUNT(*) FROM acs_objects WHERE object_id<1032;
count
-------
15
ccm_perf=# SELECT COUNT(*) FROM acs_objects;
count
-------
33510
--
Guillaume
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2005-05-11 20:02:01 | Re: Partitioning / Clustering |
| Previous Message | Tom Lane | 2005-05-11 19:38:16 | Re: Bad plan after vacuum analyze |