Re: WIP Patch: Precalculate stable functions, infrastructure v1

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(dot)polyakova(at)postgrespro(dot)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.

Thank you very much! I'll try to implement something from this.

> 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.

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