From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Frost <jeff(at)frostconsultingllc(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: strange index behaviour with different statistics target |
Date: | 2009-01-13 23:40:21 |
Message-ID: | 3485.1231890021@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jeff Frost <jeff(at)frostconsultingllc(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Frost | 2009-01-13 23:44:00 | Re: strange index behaviour with different statistics target |
Previous Message | Jeff Frost | 2009-01-13 23:23:08 | Re: strange index behaviour with different statistics target |