Re: WIP Patch: Precalculate stable functions, infrastructure v1
От | Tom Lane |
---|---|
Тема | Re: WIP Patch: Precalculate stable functions, infrastructure v1 |
Дата | |
Msg-id | 29643.1516140301@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP Patch: Precalculate stable functions, infrastructure v1 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: WIP Patch: Precalculate stable functions, infrastructure v1
(Marina Polyakova <m.polyakova@postgrespro.ru>)
Re: WIP Patch: Precalculate stable functions, infrastructure v1 (Marina Polyakova <m.polyakova@postgrespro.ru>) Re: WIP Patch: Precalculate stable functions, infrastructure v1 (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
[ 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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: WIP Patch: Precalculate stable functions, infrastructure v1
Следующее
От: David RowleyДата:
Сообщение: Re: [HACKERS] Proposal: Local indexes for partitioned table