Re: strange index behaviour with different statistics target

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.

> 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