Jeff Frost <j...@frostconsultingllc.com> writes:
> On Tue, 13 Jan 2009, Tom Lane wrote:
>> It would change the size of the sample for the table, which might
>> improve the accuracy of the stats. IIRC you'd still get the same number
>> of histogram entries and most-common-values for the other columns, but
>> they might be more accurate.
> Why would they be more accurate?
They'd be drawn from a larger sample of the table rows. If we need a
random sample of N rows for the largest stats target among the columns,
we use all those rows for deriving the stats for the other columns too.
> The planner is choosing a plan I like for the query, I'm just trying to
> understand why it's doing that since the planner thinks the gist index is
> going to give it a single row (vs the 2827 rows it actually gets) and the
> fact
> that the cost didn't change for perusing the gist index.
You'd need to ask the postgis guys whether they have an estimator for
ST_Contains that actually does anything useful. I haven't the foggiest
what the state of their stats support is.
[ looks again at the plan... ] Actually it looks like the estimator
for && is what's at issue. Estimators are attached to operators not
functions.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
