Re: strange index behaviour with different statistics target

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

In response to

Responses

Browse pgsql-performance by date

  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