Re: Bad plan after vacuum analyze - Mailing list pgsql-performance

From Guillaume Smet
Subject Re: Bad plan after vacuum analyze
Date
Msg-id 4282638E.2020307@smet.org
Whole thread Raw
In response to Re: Bad plan after vacuum analyze  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bad plan after vacuum analyze
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bad plan after vacuum analyze
Next
From: Greg Stark
Date:
Subject: Re: Partitioning / Clustering