Re: More efficient RI checks - take 2

>
> I can imagine removal of the SPI from the current implementation (and
> constructing the plans "manually"), but note that the queries I use in my
> patch are no longer that trivial. So the SPI makes sense to me because it
> ensures regular query planning.
>

As an intermediate step, in the case where we have one row, it should be
simple enough to extract that row manually, and do an SPI call with fixed
values rather than the join to the ephemeral table, yes?

> As for the tuplestore, I'm not sure the startup cost is a problem: if
> you're
> concerned about the 1-row case, the row should usually be stored in memory.
>

> > and once that is done, we could see about step #2.
>
> As I said during my review of your patch last year, I think the RI
> semantics
> has too much in common with that of triggers. I'd need more info to imagine
> such a change.
>

As a general outline, I think that DML would iterate over the 2 sets of
potentially relevant RI definitions rather than iterating over the
triggers.

The similarities between RI and general triggers are obvious, which
explains why they went that route initially, but they're also a crutch, but
since all RI operations boil down to either an iteration over a tuplestore
to do lookups in an index (when checking for referenced rows), or a hash
join of the transient data against the un-indexed table when checking for
referencing rows, and people who know this stuff far better than me seem to
think that SPI overhead is best avoided when possible. I'm looking forward
to having more time to spend on this.