Re: More efficient RI checks - take 2 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: More efficient RI checks - take 2
Date
Msg-id 20200422183600.tpl5745dfbnozi6t@alap3.anarazel.de
Whole thread Raw
In response to Re: More efficient RI checks - take 2  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: More efficient RI checks - take 2  (Corey Huinker <corey.huinker@gmail.com>)
Re: More efficient RI checks - take 2  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2020-04-22 13:46:22 -0400, Robert Haas wrote:
> On Wed, Apr 22, 2020 at 1:18 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > Well, I was actually thinking in building ready-made execution trees,
> > bypassing the planner altogether.  But apparently no one thinks that
> > this is a good idea, and we don't have any code that does that already,
> > so maybe it's not a great idea.

I was commenting on what I understood Corey to say, but was fairly
unclear about it. But I'm also far from sure that I understood Corey
correctly...


> If it's any consolation, I had the same idea very recently while
> chatting with Amit Langote. Maybe it's a bad idea, but you're not the
> only one who had it. :-)

That seems extremely hard, given our current infrastructure. I think
there's actually a good case to be made for the idea in the abstract,
but ...  The amount of logic the ExecInit* routines have is substantial,
the state they set up ss complicates. A lot of nodes have state that is
private to their .c files. All executor nodes reference the
corresponding Plan nodes, so you also need to mock up those.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: 2pc leaks fds
Next
From: Robert Haas
Date:
Subject: Re: design for parallel backup