Re: BUG #10171: Specific prepared statement cannot use bitmapOr index scan since 9.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pilum(dot)70(at)uni-muenster(dot)de
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #10171: Specific prepared statement cannot use bitmapOr index scan since 9.2
Date: 2014-04-29 14:49:27
Message-ID: 17573.1398782967@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

pilum(dot)70(at)uni-muenster(dot)de writes:
> The following query uses bitmap or index scan in 9.1, but only Nested Loop
> in 9.2 and 9.3:

Interesting. The plan actually gets stupider when it has values for the
parameters, if those values chance to be NULL.

The reason seems to be that after substituting the parameters and
constant-folding, we've got this join condition:

(t1.id2 = ''::text AND t2.id2 = ''::text) OR NULL::boolean

and the code in orclause.c is unable to realize that it can extract the
sub-AND elements as restriction clauses for t1 and t2. But it'd be
all right to ignore the constant-null OR arm, since that can't possibly
succeed.

Another way of looking at this is that we should be smart enough to throw
away the constant-null OR arm altogether at top level of WHERE, since at
top level we don't particularly care whether the OR produces FALSE or NULL
if all its other inputs are FALSE. That would probably be a more general
fix.

I'll see what I can do about this. Thanks for the report!

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2014-04-30 11:09:07 Re: BUG #10142: Downstream standby indefinitely waits for an old WAL log in new timeline on WAL Cascading replicatio
Previous Message pilum.70 2014-04-29 07:41:55 BUG #10171: Specific prepared statement cannot use bitmapOr index scan since 9.2