Re: Bad plan after vacuum analyze
| От | Guillaume Smet |
|---|---|
| Тема | Re: Bad plan after vacuum analyze |
| Дата | |
| Msg-id | 4282638E.2020307@smet.org обсуждение исходный текст |
| Ответ на | Re: Bad plan after vacuum analyze (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Bad plan after vacuum analyze
|
| Список | 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
В списке pgsql-performance по дате отправления: