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. > 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
