On Fri, Oct 26, 2012 at 6:08 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > > Interestingly, this is a case where the get_actual_variable_range patch > (commit 40608e7f, which appeared in 9.0) makes the results worse. > Before that, there was a (very arbitrary) lower bound on what we'd > believe as the selectivity of a >= condition, but now, when we know the > actual upper limit of the variable, we don't clamp the result that way. > I think the clamp must have been saving you in your previous version, > because it more-or-less-accidentally accounted for the end value not > being unique. IIRC, that patch was performing an index query (index_last) to get the real largest value, right? How many duplicates would you think the planner would require to choose another (better) plan? Because once you've accessed that last index page, it would be rather trivial finding out how many duplicate tids are in that page and, with a small CPU cost (no disk access if you don't query other index pages) you could verify the assumption of near-uniqueness. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
