Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size

On 2022-07-05 Tu 15:04, Andrew Dunstan wrote:
> On 2022-07-05 Tu 14:36, Andres Freund wrote:
>>
>>>> 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.

We're still working on it. We've made substantial progress but there are
some tests failing that we need to 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.

Actually, it's not the same name: JsonCoercionsState vs
JsonCoercionState. But I agree that it's a subtle enough difference that
we should use something more obvious. Maybe JsonCoercionStates instead
of JsonCoercionsState? The plural at the end would be harder to miss.

cheers

andrew

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