[HACKERS] eval_const_expresisions and ScalarArrayOpExpr - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject [HACKERS] eval_const_expresisions and ScalarArrayOpExpr
Date
Msg-id 3be3b82c-e29c-b674-2163-bf47d98817b1@iki.fi
Whole thread Raw
Responses Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Eval_const_expressions() doesn't know about ScalarArrayOpExpr. We 
simplify the arguments, but if all the arguments are booleans, we don't 
take the obvious step of replacing the whole expression with a boolean 
Const. For example:

postgres=# explain select * from foo where 1 IN (1,2,3);
                          QUERY PLAN
-------------------------------------------------------------
  Result  (cost=0.00..35.50 rows=2550 width=4)
    One-Time Filter: (1 = ANY ('{1,2,3}'::integer[]))
    ->  Seq Scan on foo  (cost=0.00..35.50 rows=2550 width=4)
(3 rows)

I would've expected that to be fully evaluated at plan-time, and 
optimized away.

That seems like an oversight. I guess that scenario doesn't happen very 
often in practice, but there's no reason not to do it when it does. 
Patch attached.

On a side-note, I find it a bit awkward that ScalarArrayOpExpr uses a 
2-element List to hold the scalar and array arguments. Wouldn't it be 
much more straightforward to have explicit "Expr *scalararg" and "Expr 
*arrayarg" fields?

- Heikki


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachment

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] snapbuild woes
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Time based lag tracking for logical replication