Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
Date
Msg-id 3f21e27b-3710-e2c5-329b-8f0c329130d0@dunslane.net
Whole thread Raw
In response to Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size  (Andres Freund <andres@anarazel.de>)
Responses Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
List pgsql-hackers
On 2022-07-05 Tu 14:36, Andres Freund wrote:
> Hi,
>
> On 2022-06-24 10:29:06 -0400, Andrew Dunstan wrote:
>> On 2022-06-23 Th 21:51, Andres Freund wrote:
>>> On 2022-06-23 16:38:12 +0900, Michael Paquier wrote:
>>>> On Tue, Jun 21, 2022 at 05:41:07PM -0400, Andrew Dunstan wrote:
>>>>> 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.
> Any updates here?


Not yet. A colleague and I are working on it. I'll post a status this
week if we can't post a fix.


>
> I'd mentioned the significant space use due to all JsonCoercionsState for all
> the types. Another related aspect is that this code is just weird - the same
> struct name (JsonCoercionsState), nested in each other?
>
>     struct JsonCoercionsState
>     {
>         struct JsonCoercionState
>         {
>             JsonCoercion *coercion; /* coercion expression */
>             ExprState  *estate; /* coercion expression state */
>         }           null,
>                     string,
>         numeric    ,
>                     boolean,
>                     date,
>                     time,
>                     timetz,
>                     timestamp,
>                     timestamptz,
>                     composite;
>     }           coercions;      /* states for coercion from SQL/JSON item
>                                  * types directly to the output type */
>
> Also note the weird numeric indentation that pgindent does...


Yeah, we'll try to fix that.


>
>
>> The attached very small patch applies on top of your 0002 and deals with
>> the FmgrInfo complaint.
> Now that the FmgrInfo is part of a separately allocated struct, that doesn't
> seem necessary anymore.


Right, but you complained that we should do it the same way as it's done
elsewhere, so I thought I'd do that anyway.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: PSA: Autoconf has risen from the dead
Next
From: Tom Lane
Date:
Subject: Re: PSA: Autoconf has risen from the dead