On Tue, 13 Jan 2009, Tom Lane wrote:
Jeff Frost <jeff@xxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 916-647-6411 FAX: 916-405-4032
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
