Hi, On 2022-06-23 16:38:12 +0900, Michael Paquier wrote: > On Tue, Jun 21, 2022 at 05:41:07PM -0400, Andrew Dunstan wrote: > > On 2022-06-21 Tu 17:25, Andres Freund wrote: > >> On 2022-06-21 17:11:33 -0400, Andrew Dunstan wrote: > >>> I and a couple of colleagues have looked it over. As far as it goes the > >>> json fix looks kosher to me. I'll play with it some more. > >> > >> Cool. > >> > >> Any chance you could look at fixing the "structure" of the generated > >> expression "program". The recursive ExecEvalExpr() calls are really not > >> ok... > > By how much does the size of ExprEvalStep go down once you don't > inline the JSON structures as of 0004 in [1]? And what of 0003?
0004 gets us back to 64 bytes, if 0003 is applied first. 0003 alone doesn't yield a size reduction, because obviously 0004 is the bigger problem. Applying just 0004 you end up with 88 bytes. > The JSON portions seem like the largest portion of the cake, though both are > must-fixes. Yep. > > Yes, but I don't guarantee to have a fix in time for Beta2. > > IMHO, it would be nice to get something done for beta2. Now the > thread is rather fresh and I guess that more performance study is > required even for 0004, so.. I don't think there's a whole lot of performance study needed for 0004 - the current state is obviously wrong. I think Andrew's beta 2 comment was more about my other architectural complains around the json expression eval stuff. > Waiting for beta3 would a better move at this stage. Is somebody confident > enough in the patches proposed? 0001 is the one that needs to most careful analysis, I think. 0002 I'd be fine with pushing after reviewing it again. For 0003 David's approach might be better or worse, it doesn't matter much I think. 0004 is ok I think, perhaps with the exception of quibbling over some naming decisions? Greetings, Andres Freund