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

From Amit Langote
Subject Re: More efficient RI checks - take 2
Date
Msg-id CA+HiwqFAbp+EZ1iccoL-8P_PHmWY+W8EmmDmTBmQkyxV8zNFpQ@mail.gmail.com
Whole thread Raw
In response to Re: More efficient RI checks - take 2  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Thu, Apr 23, 2020 at 2:18 AM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> On 2020-Apr-22, Andres Freund wrote:
> > I assume that with constructing plans "manually" you don't mean to
> > create a plan tree, but to invoke parser/planner directly? I think
> > that'd likely be better than going through SPI, and there's precedent
> > too.
>
> 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.

We do have an instance in validateForeignKeyConstraint() of "manually"
enforcing RI:

If RI_Initial_Check() (a relatively complex query) cannot be
performed, the referencing table is scanned manually and each tuple
thus found is looked up in the referenced table by using
RI_FKey_check_ins(), a simpler query.

Ironically though, RI_Initial_Check() is to short-circuit the manual algorithm.

-- 
Amit Langote
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: sqlsmith crash incremental sort
Next
From: Amit Langote
Date:
Subject: Re: [PATCH] Fix Null pointer dereferences (pgoutput.c)