Marina Polyakova <m.polyak...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers