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).
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
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 that constant ArrayRef expressions weren't
>>> simplified). So
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 it's been languishing in a git branch for
>>
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 reduce the amount
>>> of duplicative boile
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 think I wrote
>> it
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 *scalararg" and "Expr
>>> *a
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.
Patch attached.
Yea
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 it's a lack-of-round-
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);
10 matches
Mail list logo
