From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Amit Langote <amitlangote09(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru> |
Subject: | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |
Date: | 2022-08-09 19:59:44 |
Message-ID: | 5010c184-088d-f98b-18ea-40ee63be6b04@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8/9/22 2:57 PM, Andres Freund wrote:
> Hi,
>
> On 2022-08-09 14:04:48 -0400, Jonathan S. Katz wrote:
>>>> 2. Recommend holding up the v15 release to allow for the code to be
>>>> redesigned and fixed (as based on Andres' estimates, this would push
>>>> the release out several months).
>
> Obviously that's a question of the resources brought to bear.
>
> From my angle: I've obviously some of my own work to take care of as well, but
> it's also just hard to improve something that includes a lot of undocumented
> design decisions.
*nod*
>>>> 4. Revert the feature set and redesign and try to include for v16
> Unless we decide on 4 immediately, I think it might be worth starting a
> separate thread to get more attention. The subject doesn't necessarily have
> everyone follow along.
*nod* I'll do this shortly.
>> Rereading the thread for the umpteenth time, I have seen Amit working
>> through Andres' concerns. From my read, the ones that seem pressing are:
>>
>> * Lack of design documentation, which may be leading to some of the general
>> design concerns
>
>> * The use of substransactions within the executor, though docs explaining
>> the decisions on that could alleviate it (I realize this is a big topic and
>> any summary I give won't capture the full nuance)
>
> I don't think subtransactions per-se are a fundamental problem. I think the
> error handling implementation is ridiculously complicated, and while I started
> to hack on improving it, I stopped when I really couldn't understand what
> errors it actually needs to handle when and why.
Ah, thanks for the clarification. That makes sense.
>> * Debate on how to handle the type coercions
>
> That's partially related to the error handling issue above.
>
> One way this code could be drastically simplified is to force all
> type-coercions to go through the "io coercion" path, which could be
> implemented as a single execution step (which thus could trivially
> start/finish a subtransaction) and would remove a lot of the complicated code
> around coercions.
If we went down this path, would this make you feel more comfortable
with including this work in the v15 release?
Thanks,
Jonathan
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2022-08-09 20:00:37 | Re: optimize lookups in snapshot [sub]xip arrays |
Previous Message | Jonathan S. Katz | 2022-08-09 19:50:36 | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |