Josh Berkus <j...@agliodbs.com> writes:
>> If you mean the indexscan optimization, we do know how to estimate the
>> cost of the indexscans, because that depends mostly on the behavior of
>> the added < or > condition(s). This does not imply knowing how to
>> estimate the behavior of >>= itself.
> If we can estimate the cost of the indexscan, why can't we estimate the
> rowcount?
Because the estimated rowcount is derived long before we consider whether
to use an indexscan at all, and indeed must be computable whether the
table has any related index or not. The special-indexscan-qual code is
*not* a substitute for providing a selectivity estimator.
It's possible that we could build simple estimators for these operators
that just turn the problem into a range estimation and then pass it off
to somewhere else, but nobody has tried.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
