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

[Jonathan S. Katz]

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.

Thanks,

Jonathan

If we went down this path, would this make you feel more comfortable with including this work in the v15 release?

OpenPGP_signature
Description: OpenPGP digital signature