Re: WIP Patch: Precalculate stable functions, infrastructure v1

Hello, hackers!

Here there's a 9-th version of the patches for the precalculation of
stable or immutable functions, stable or immutable operators and other
nonvolatile expressions. This is a try to execute cached expressions as
PARAM_EXEC, thanks to the comments of Tom Lane and Andres Freund [1].

v9-0001-Move-the-FreeExecutorState-call-in-the-StoreAttrD.patch
- a patch in which the call of FreeExecutorState() is used only after
copying the result from the executor memory context.

v9-0002-Compile-check-constraints-for-domains-into-separa.patch
- a patch for compiling CoerceToDomain nodes into separate ExprStates so
they can be used with lists of their own cached expressions that are
compiled as PARAM_EXEC.

v9-0003-Precalculate-stable-immutable-expressions-infrast.patch
- a patch that simply adds new nodes / new fields to existing nodes and
accordingly adds / changes the main functions of the nodes for all of
them.

v9-0004-Precalculate-stable-immutable-expressions-executo.patch
- a patch for compiling cached expressions as PARAM_EXEC.

v9-0005-Precalculate-stable-and-immutable-functions-plann.patch
- the main patch that adds the CachedExpr nodes in
eval_const_expressions() and processes the cached expressions as
ordinary expressions in other parts of the code.

v9-0006-Precalculate-stable-immutable-expressions-prepare.patch
- a patch for supporting cached expressions in prepared statements.

As usual any suggestions are welcome!

[1] On 24-01-2018 22:20, Andres Freund wrote:
> To me, who has *not* followed the thread in detail, it sounds like the
> relevant data shouldn't be stored inside the expression itself. For
> one, we do not want to have to visit every single simple expression and
> reset them, for another it architecturally doesn't seem the right place
> to me. Storing all cached values in an EState or ExprContext (the
> latter referring to the former) somewhat alike the values for Param's
> sounds a lot more reasonable to me.

> Besides that it seems to make it a lot easier to reset the values, it
> also seems like it makes it a lot cleaner to cache stable functions
> across multiple expressions in different places in a query? ISTM having
> expression steps to actually compute the expression value in every
> referencing expression is quite the waste.

The problem is that with the function expression_planner some
expressions are planned at compile time.. You can also use the function
ExecInitExpr without the parent PlanState node => without a pointer to
the corresponding EState.

--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company