Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
От | Andrew Dunstan |
---|---|
Тема | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |
Дата | |
Msg-id | 6f09b162-725f-53c7-a4b4-048f50ef3eb2@dunslane.net обсуждение исходный текст |
Ответ на | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
|
Список | pgsql-hackers |
On 2022-06-23 Th 21:51, Andres Freund wrote: > 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. Right. That's being worked on but it's not going to be a mechanical fix. > > >> 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? > > The attached very small patch applies on top of your 0002 and deals with the FmgrInfo complaint. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: