From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | eval_const_expresisions and ScalarArrayOpExpr |
Date: | 2017-05-11 15:03:29 |
Message-ID: | 3be3b82c-e29c-b674-2163-bf47d98817b1@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
0001-Const-eval-ScalarArrayOpExprs.patch | invalid/octet-stream | 2.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-05-11 15:08:11 | Re: Time based lag tracking for logical replication |
Previous Message | Petr Jelinek | 2017-05-11 14:59:18 | Re: snapbuild woes |