>> Like for the previous patches it seems that there is
>> no obvious performance degradation too on regular queries (according
>> to
>> pgbench).
>
> pgbench probably isn't a very good test for this sort of thing - it
> only issues very short-running queries where the cost of evaluating
> expressions is a relatively small part of the total cost. Even if
> things get worse, I'm not sure if you'd see it.
If there's a mistake, for example, more than 1 try to replace cached
expressions in the whole query tree, results of "in buffer test" or
"mostly cache test" can different a little..
> I'm not sure exactly
> how you could construct a test case that could be harmed by this patch
> - I guess you'd want to initialize lots of CacheExprs but never make
> use of the caching usefully?
As I mentioned in the first letter about this feature it will be useful
for such text search queries [1]:
SELECT COUNT(*) FROM messages WHERE body_tsvector @@
to_tsquery('postgres');
And I'm not sure that it is logical to precalculate stable and immutable
functions themselves, but not to precalculate expressions that behave
like stable/immutable functions; precalculate some types of operators
and not to precalculate others (ScalarArrayOpExpr, RowCompareExpr). My
patch solves the problem that not all nodes are simplified in
eval_const_expressions_mutator (for example, ScalarArrayOpExpr) and
consts of other types now behave more like ordinary consts (for example,
composite types, coerce expressions, ConvertRowtypeExpr).
> It could also be useful to test things like TPC-H to see if you get an
> improvement.
I saw the examples of queries in TPC-H tests. If I'm not wrong they are
not the target tests for this functionality (nothing will be
precalculated). But it's a good idea to check that there's no a
performance degradation on them too.
[1]
https://www.postgresql.org/message-id/ba261b9fc25dea4069d8ba9a8fcadf35%40postgrespro.ru
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company