Re: Broken selectivity with special inet operators - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Broken selectivity with special inet operators
Date
Msg-id 629.1316642270@sss.pgh.pa.us
Whole thread Raw
In response to Re: Broken selectivity with special inet operators  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Broken selectivity with special inet operators  (Josh Berkus <josh@agliodbs.com>)
List pgsql-bugs
Josh Berkus <josh@agliodbs.com> 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 we implemented the rewrite to < and > for the actual execution, but
> not for cost estimates?

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.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Guillaume Smet
Date:
Subject: Re: BUG #6219: date_part() function producting incorrect year
Next
From: Josh Berkus
Date:
Subject: Re: Broken selectivity with special inet operators