> 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.
Right, that's why I'm asking. I'd like to reuse code ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://
Josh Berkus 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 estimat
> 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 indexsca
Josh Berkus writes:
> On 9/21/11 1:56 PM, Tom Lane wrote:
>> A look in pg_operator will show you that these operators have no
>> associated selectivity estimators at all. It's not so much "broken"
>> as "unimplemented".
> Oh! I was assuming that the special case code kicked in regardless.
> So
On 9/21/11 1:56 PM, Tom Lane wrote:
> Josh Berkus writes:
>> Summary: special inet operators ( << >> <<= =>> ) are
>> up to 100X off in estimating rowcounts
>
> A look in pg_operator will show you that these operators have no
> associated selectivity estimators at all. It's not so much
Josh Berkus writes:
> Summary: special inet operators ( << >> <<= =>> ) are
> up to 100X off in estimating rowcounts
A look in pg_operator will show you that these operators have no
associated selectivity estimators at all. It's not so much "broken"
as "unimplemented".
regression=# se
Summary: special inet operators ( << >> <<= =>> ) are
up to 100X off in estimating rowcounts
Type: performance
Severity: normal
Tested on: 9.1.0
Description:
We've been noticing that row estimates for queries which use the =>> and
<<= operators for inet data were way, way off. We fina
