Re: Fwd: WIP Patch: Precalculate stable functions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fwd: WIP Patch: Precalculate stable functions
Date: 2017-04-20 17:31:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)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

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2017-04-20 18:05:40 Re: AGG_HASHED cost estimate
Previous Message Fabien COELHO 2017-04-20 17:17:44 Re: pgbench more operators & functions