From: Guillaume Smet <guillaume_ml@smet.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: josh@agliodbs.com
Cc: pgsql-performance@postgresql.org
Subject: Re: Bad plan after vacuum analyze
Date: Wed, 11 May 2005 21:57:02 +0200
Message-ID: <4282638E.2020307@smet.org> (raw)
In-Reply-To: <14301.1115840296@sss.pgh.pa.us>
References: <42823F94.8050009@smet.org>
<200505111110.15983.josh@agliodbs.com>
<13964.1115837926@sss.pgh.pa.us>
<42825DBB.7000703@smet.org>
<14301.1115840296@sss.pgh.pa.us>
> 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: guillaume_ml@smet.org, tgl@sss.pgh.pa.us, josh@agliodbs.com
Subject: Re: Bad plan after vacuum analyze
In-Reply-To: <4282638E.2020307@smet.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox