Re: WIP Patch: Precalculate stable functions, infrastructure v1 - Mailing list pgsql-hackers

Thank you so much for your comments!! I'll answer a bit later because 
now I'm trying to find a test for int128 on Solaris 10.. [1]

On 17-01-2018 1:05, Tom Lane wrote:
> [ I'm sending this comment separately because I think it's an issue
> Andres might take an interest in. ]
> 
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> [ v7-0001-Precalculate-stable-and-immutable-functions.patch ]
> 
> Another thing that's bothering me is that the execution semantics
> you're proposing for CachedExpr seem rather inflexible.  AFAICS, once a
> CachedExpr has run once, it will hang on to the result value and keep
> returning that for the entire lifespan of the compiled expression.
> We already noted that that breaks plpgsql's "simple expression"
> logic, and it seems inevitable to me that it will be an issue for
> other places as well.  I think it'd be a better design if we had some
> provision for resetting the cached values, short of recompiling the
> expression from scratch.
> 
> One way that occurs to me to do this is to replace the simple boolean
> isExecuted flags with a generation counter, and add a master generation
> counter to ExprState.  The rule for executing CachedExpr would be "if 
> my
> generation counter is different from the ExprState's counter, then
> evaluate the subexpression and copy the ExprState's counter into mine".
> Then the procedure for forcing recalculation of cached values is just 
> to
> increment the ExprState's counter.  There are other ways one could 
> imagine
> doing this --- for instance, I initially thought of keeping the master
> counter in the ExprContext being used to run the expression.  But you 
> need
> some way to remember what counter value was used last with a particular
> expression, so probably keeping it in ExprState is better.
> 
> Or we could just brute-force it by providing a function that runs 
> through
> a compiled expression step list and resets the isExecuted flag for each
> EEOP_CACHEDEXPR_IF_CACHED step it finds.  A slightly less brute-force
> way is to link those steps together in a list, so that the function
> doesn't have to visit irrelevant steps.  If the reset function were 
> seldom
> used then the extra cycles for this wouldn't be very expensive.  But 
> I'm
> not sure it will be seldom used --- it seems like plpgsql simple
> expressions will be doing this every time --- so I think the counter
> approach might be a better idea.
> 
> I'm curious to know whether Andres has some other ideas, or whether he
> feels this is all a big wart on the compiled-expression concept.  I 
> don't
> think there are any existing cases where we keep any meaningful state
> across executions of a compiled-expression data structure; maybe that's
> a bad idea in itself.
> 
>             regards, tom lane

[1] 
https://www.postgresql.org/message-id/18209.1516059711%40sss.pgh.pa.us

-- 
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company