On Tue, Sep 6, 2011 at 19:51, Tom Lane wrote:
> Marti Raudsepp writes:
>> So it seems the more fundamental issue is that b=0 and b='0'
>> conditions are normalized differently when b is smallint.
>
> That's not a "fundamental issue", if by that you mean that it's a bug to
> be fixed.
That was a
Marti Raudsepp writes:
> On Mon, Sep 5, 2011 at 21:01, Tom Lane wrote:
>> What we have to start with is WHERE b = 0::smallint, which the planner
>> is able to prove implies the index predicate WHERE b = 0::integer,
>> so both indexes are considered. Â But the check for predicate redundancy
>> in
On Mon, Sep 5, 2011 at 21:01, Tom Lane wrote:
> What we have to start with is WHERE b = 0::smallint, which the planner
> is able to prove implies the index predicate WHERE b = 0::integer,
> so both indexes are considered. But the check for predicate redundancy
> in choose_bitmap_and() only uses s
Marti Raudsepp writes:
> This simple query shouldn't cause two bitmap index scans:
> EXPLAIN select * from test where b='0';
> Bitmap Heap Scan on test (cost=1056.68..8200.12 rows=29839 width=314)
>Recheck Cond: ((b = 0) AND (b = 0::smallint))
>-> BitmapAnd (cost=1056.68..1056.68 rows
Hi list,
This simple query shouldn't cause two bitmap index scans:
EXPLAIN select * from test where b='0';
Bitmap Heap Scan on test (cost=1056.68..8200.12 rows=29839 width=314)
Recheck Cond: ((b = 0) AND (b = 0::smallint))
-> BitmapAnd (cost=1056.68..1056.68 rows=5237 width=0)
