Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

2017-10-01 Thread Tom Lane
I wrote: > This patch no longer applies cleanly on HEAD, so here's a rebased version > (no substantive changes). As before, I think the most useful review task > would be to quantify whether it makes planning noticeably slower. Rebased again (over the arrays-of-domains patch).

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

2017-09-12 Thread Tom Lane
I wrote: > Looking at the patch, it still seems solid, but I remember that one > thing I was concerned about was whether the more generalized code > was any slower. Not sure about a good test case to measure that > though --- const-simplification isn't a large chunk of most workloads. This patch

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

2017-05-12 Thread Robert Haas
On Fri, May 12, 2017 at 12:55 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, May 12, 2017 at 12:04 PM, Tom Lane wrote: >>> Actually, I now remember that I wrote that while at Salesforce (because >>> they'd run into the problem

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

2017-05-12 Thread Tom Lane
Robert Haas writes: > On Fri, May 12, 2017 at 12:04 PM, Tom Lane wrote: >> Actually, I now remember that I wrote that while at Salesforce (because >> they'd run into the problem that constant ArrayRef expressions weren't >> simplified). So that means

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

2017-05-12 Thread Robert Haas
On Fri, May 12, 2017 at 12:04 PM, Tom Lane wrote: > Heikki Linnakangas writes: >> On 05/11/2017 06:21 PM, Tom Lane wrote: >>> Yeah, I think it's a lack-of-round-tuits situation. Your patch reminds >>> me of a more ambitious attempt I made awhile back to

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

2017-05-12 Thread Tom Lane
Heikki Linnakangas writes: > On 05/11/2017 06:21 PM, Tom Lane wrote: >> Yeah, I think it's a lack-of-round-tuits situation. Your patch reminds >> me of a more ambitious attempt I made awhile back to reduce the amount >> of duplicative boilerplate in eval_const_expressions. I

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

2017-05-11 Thread Tom Lane
Heikki Linnakangas writes: > On 05/11/2017 06:21 PM, Tom Lane wrote: >>> 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

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

2017-05-11 Thread Heikki Linnakangas
On 05/11/2017 06:21 PM, Tom Lane wrote: Heikki Linnakangas writes: Eval_const_expressions() doesn't know about ScalarArrayOpExpr. ... 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.

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

2017-05-11 Thread Tom Lane
Heikki Linnakangas writes: > Eval_const_expressions() doesn't know about ScalarArrayOpExpr. > ... > 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. Yeah, I think

[HACKERS] eval_const_expresisions and ScalarArrayOpExpr

2017-05-11 Thread Heikki Linnakangas
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);