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

From Robert Haas
Subject Re: More efficient RI checks - take 2
Date
Msg-id CA+Tgmobb2_sm8PZ16_dqevUktcjT8OnZ5xvv=AFtxWWjf28VxA@mail.gmail.com
Whole thread Raw
In response to Re: More efficient RI checks - take 2  (Andres Freund <andres@anarazel.de>)
Responses Re: More efficient RI checks - take 2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Apr 22, 2020 at 2:36 PM Andres Freund <andres@anarazel.de> wrote:
> > 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.

Right -- the idea I was talking about was to create a Plan tree
without using the main planner. So it wouldn't bother costing an index
scan on each index, and a sequential scan, on the target table - it
would just make an index scan plan, or maybe an index path that it
would then convert to an index plan. Or something like that.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: design for parallel backup
Next
From: Tom Lane
Date:
Subject: Regression instability + performance issue in TRIGGERS view