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

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

In response to

Browse pgsql-hackers by date

  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