On Tue, 13 Jan 2009, Tom Lane wrote:
> Jeff Frost <jeff@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.
Oh, ok, thanks Tom. That makes sense now.
>
>> 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.
Thanks, I'll see if I can dig up some info on that and/or post to the
postgis list if I can't turn anything up.
--
Jeff Frost, Owner <jeff@frostconsultingllc.com>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 916-647-6411 FAX: 916-405-4032