Thread: Simple Optimization Problem

    I need to run a report using some parameters that are optional, I'm
doing this by labeling "0" as the optional value.  IE here is a
simplified example:

CREATE TABLE po (po_id int4 PRIMARY KEY, data text);
    (insert a bunch of rows)

ftc=> explain select * from po where po_id=8888;
NOTICE:  QUERY PLAN:

Index Scan using ipo_poid_units on po  (cost=2.05 size=1 width=94)

EXPLAIN

ftc=> explain select * from po where (po_id=8888 or 0=8888);
NOTICE:  QUERY PLAN:

Seq Scan on po  (cost=449.96 size=1751 width=94)

EXPLAIN

    I was hoping PostgreSQL could optimize out the boolean condition
given in the where clause, but it causes it to disregard the index
instead of throwing out 0=8888 in the first stage.

    This is the only way I can think to do this, I have crystal reports
send through the SQL instead of doing the whole thing itself(Which
involves returning all possible rows... Sigh)... This query is taking 20
minutes as a result... Is there any hope in 6.5 of the optimizer
handling this better?

David Secret
MIS Director
Kearney Development Co., Inc.

I have added this to our TODO list as:
process const=const parts of OR clause first 


>     I need to run a report using some parameters that are optional, I'm
> doing this by labeling "0" as the optional value.  IE here is a
> simplified example:
> 
> CREATE TABLE po (po_id int4 PRIMARY KEY, data text);
>     (insert a bunch of rows)
> 
> ftc=> explain select * from po where po_id=8888;
> NOTICE:  QUERY PLAN:
> 
> Index Scan using ipo_poid_units on po  (cost=2.05 size=1 width=94)
> 
> EXPLAIN
> 
> ftc=> explain select * from po where (po_id=8888 or 0=8888);
> NOTICE:  QUERY PLAN:
> 
> Seq Scan on po  (cost=449.96 size=1751 width=94)
> 
> EXPLAIN
> 
>     I was hoping PostgreSQL could optimize out the boolean condition
> given in the where clause, but it causes it to disregard the index
> instead of throwing out 0=8888 in the first stage.
> 
>     This is the only way I can think to do this, I have crystal reports
> send through the SQL instead of doing the whole thing itself(Which
> involves returning all possible rows... Sigh)... This query is taking 20
> minutes as a result... Is there any hope in 6.5 of the optimizer
> handling this better?
> 
> David Secret
> MIS Director
> Kearney Development Co., Inc.
> 
> 
> 


--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> I have added this to our TODO list as:
>     process const=const parts of OR clause first 

I think that would be quite the wrong way to approach it.  What we
need is a general-purpose rewriter phase that tries to evaluate
constant subexpressions, and is applied after the rest of rewrite
but before planner/optimizer.  In this case
select * from po where (po_id=8888 or 0=8888);

would be reduced to
select * from po where (po_id=8888 or FALSE);

and then
select * from po where (po_id=8888);

which the optimizer knows what to do with.  (cnfify() does some of this
but not enough.)

>> Is there any hope in 6.5 of the optimizer
>> handling this better?

Not for 6.5.  6.6 or 6.7 maybe...
        regards, tom lane