Re: Rethinking the parameter access hooks for plpgsql's benefit

On Sun, Mar 8, 2015 at 11:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Objections?  Even better ideas?

I object on the grounds that we're three weeks past the deadline for
the last CommitFest, and that we should be trying to get committed
those patches that were submitted on time, not writing new ones that
will further increase the amount of reviewing that needs to be done
before we can get to beta, and perhaps the bug count of that
eventually when it arrives.  In particular, I think that the fact that
you haven't made more of an effort to give the GROUPING SETS patch a
more detailed review is quite unfair to Andrew Gierth.  But regardless
of that, this is untimely and should be pushed to 9.6.

On the technical side, I do agree that the requirement to allocate and
zero an array for every new simple expression is unfortunate, but I'm
not convinced that repeatedly invoking the hook-function is a good way
to solve that problem.  Calling the hook-function figures to be
significantly more expensive than an array-fetch, so you can almost
think of the ParamListInfo entries themselves as a cache of data
retrieved from the hook function.  In that view of the world, the
problem here is that initializing the cache is too expensive.  Your
solution to that is to rip the cache out completely, but what would be
better is keep the cache and make initializing it cheaper - e.g. by
sharing one ParamListInfo across all expressions in the same scope; or
by not zeroing the memory and instead tracking the the first N slots
are the only ones we've initialized; or $your_idea_here.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company