Marina Polyakova <m.polyakova@postgrespro.ru> writes:
> Now in Postgresql only immutable functions are precalculated; stable
> functions are calculated for every row so in fact they don't differ from
> volatile functions.
> There's a proposal to precalculate stable and immutable functions (=
> calculate once for all output rows, but as many times as function is
> mentioned in query), if they don't return a set and their arguments are
> constants or recursively precalculated functions.
Have you looked at the previous efforts in this direction? The last
discussion I can find is
https://www.postgresql.org/message-id/flat/CABRT9RA-RomVS-yzQ2wUtZ%3Dm-eV61LcbrL1P1J3jydPStTfc6Q%40mail.gmail.com
In particular, that relied on the planner to decide which subtrees were
worth caching and insert marker nodes for the purpose. I'm not certain
that that's better than putting the intelligence into execExpr.c, but
I'm not sure it isn't either. In principle we could afford to spend
more effort on making such determinations at plan time than we should
do at executor startup. Also, the fundamental implementation seemed
less invasive, in that only the marker node type had to know about the
caching behavior, whereas I gather from your description that what you
are doing is going to end up touching almost all node types.
v10's new expression eval technology is sufficiently different that
it may well be that that old approach isn't very relevant anymore.
But it would be a good idea to look.
regards, tom lane
