Re: Bad plan after vacuum analyze

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

In response to

Responses

Browse pgsql-performance by date

  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