Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

Dmitry Dolgov <9erthalion6(at)gmail(dot)com> writes:
> I tried to experiment a bit with this patch, hope it may be helpful.

Thanks for reviewing!

I took your idea of just running pgbench results, and adapted it to these
test cases:

select * from test where 1 = 1 or 1 = 2;

select * from test where 1 = 1 and 1 = 2;

select * from test where 1 in (1, 2);

select * from test where id in (1,2);

where the test table is just created with
create table test (id int);
and contains no data.

For me, the first, second, and fourth cases are within 1% of the
same speed with or without the patch; some a bit slower, some a
bit faster, but really all of those results are barely above the
noise floor. The third case is distinctly faster (~8%) with patch;
but since we're emitting a better plan, with no runtime WHERE test,
that's probably more about reduced executor overhead than anything else.

I did find one case where the patch makes things significantly slower:

select * from test where true is true
and true is true
and true is true
and true is true
... (100 times altogether)

That's a full 25% slower with the patch. Investigation confirms
that the extra cost can be blamed on using evaluate_expr() to
simplify BooleanTest nodes, in place of the specialized logic
that's there now. I don't feel bad about the other places where
evaluate_expr() is used: either they were like that before, or
the case wasn't const-simplified at all, so that even with some
overhead we can be pretty sure life is better with the patch.
But there's room to argue that BooleanTest occurs often enough that
it's worth having bespoke logic to simplify it, if that logic isn't too
complicated which it really isn't. So I'm inclined to undo the part
of the patch that turns BooleanTest processing into a generic case,
as per attached updated patch. Otherwise I think we can figure that
performance isn't a problem.

> Speaking about the code, everything looks fine. As for me, some
> variables could be named in a more self-explanatory way (e.g
> `ece_evaluate_expr`, where `ece` is `eval_const_expresisions`, or
> `saop`, which is `ScalarArrayOp`), but it's minor.

I'm disinclined to change the usage of "saop" here --- that's already
in use in lots of code touching ScalarArrayOp, so even if we had a better
idea, this patch isn't the place to change it. I'd be fine with changing
the "ece_" prefix, but I don't want to spell out eval_const_expressions
altogether; do you have a different abbreviation suggestion?

> I wonder if it makes sense in this patch also deal with the following
> situation?

> explain analyze select * from test where 1 in (select 1);

No; lots of people depend on the fact that a sub-select is an optimization
fence in that way. If we were going to change that it'd need to be
carefully thought through, and I don't think it should happen as a side
effect of what's mostly a refactoring patch. The code changes wouldn't
be anywhere near this patch, either ...

regards, tom lane