Re: [WIP] Caching constant stable expressions per execution - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [WIP] Caching constant stable expressions per execution
Date
Msg-id 23934.1315695091@sss.pgh.pa.us
Whole thread Raw
In response to [WIP] Caching constant stable expressions per execution  (Marti Raudsepp <marti@juffo.org>)
Responses Re: [WIP] Caching constant stable expressions per execution
Re: [WIP] Caching constant stable expressions per execution
List pgsql-hackers
Marti Raudsepp <marti@juffo.org> writes:
> This is a proof of concept patch for recognizing stable function calls
> with constant arguments and only calling them once per execution. I'm
> posting it to the list to gather feedback whether this is a dead end
> or not.

Hmm.  This is an interesting hack, but I'm not sure it's more than a
hack.

Usually what people have meant when they ask for "function caching"
is that multiple executions of a given stable function with the same
argument values be folded to just one execution.  In the general case
that would require some sort of hash table in which we memoize sets of
argument values and the corresponding result.  The reason that I've
generally discouraged this line of thought is that I see no way that
such a hash table could be managed or searched with sufficient
efficiency to make it a win.

What you've done here is to solve the problem for the special case of
a single (textual) instance of the function called with
plan-time-constant arguments.  While that's probably a common case,
I'm not sure it's common enough to justify extra planner and executor
complexity.

The patch as given has a bunch of implementation issues, but I think
it's close enough for crude performance testing, and your numbers do
show a potential performance benefit.  The question that I think is
unresolved is whether the set of cases covered is wide enough to be
useful in practice.  I have no data on that ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: [REVIEW] prepare plans of embedded sql on function start
Next
From: Tom Lane
Date:
Subject: Re: [REVIEW] prepare plans of embedded sql on function start