Re: WIP Patch: Precalculate stable functions, infrastructure v1

From: Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>
Subject: Re: WIP Patch: Precalculate stable functions, infrastructure v1
Date: 2018-05-24 13:00:33
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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].

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

- 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.

- 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

- a patch for compiling cached expressions as PARAM_EXEC.

- 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.

- 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:
The Russian Postgres Company

Attachment Content-Type Size
v9-0001-Move-the-FreeExecutorState-call-in-the-StoreAttrD.patch text/x-diff 1.4 KB
v9-0002-Compile-check-constraints-for-domains-into-separa.patch text/x-diff 7.1 KB
v9-0003-Precalculate-stable-immutable-expressions-infrast.patch text/x-diff 24.8 KB
v9-0004-Precalculate-stable-immutable-expressions-executo.patch text/plain 65.2 KB
v9-0005-Precalculate-stable-and-immutable-functions-plann.patch text/plain 465.8 KB
v9-0006-Precalculate-stable-immutable-expressions-prepare.patch text/x-diff 26.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2018-05-24 13:00:57 Re: A Japanese-unfriendy error message contruction
Previous Message ramsiddu007 2018-05-24 12:57:14 Function Overloading