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 20200422184217.uxuucy4woeb4yxpq@alap3.anarazel.de
Whole thread Raw
In response to Re: More efficient RI checks - take 2  (Corey Huinker <corey.huinker@gmail.com>)
List pgsql-hackers
Hi,

On 2020-04-08 13:55:55 -0400, Corey Huinker wrote:
> In doing my initial attempt, the feedback I was getting was that the people
> who truly understood the RI checks fell into the following groups:
> 1. people who wanted to remove the SPI calls from the triggers
> 2. people who wanted to completely refactor RI to not use triggers
> 3. people who wanted to completely refactor triggers

FWIW, for me these three are largely independent avenues:

WRT 1: There's a lot of benefit in reducing the per-call overhead of
RI. Not going through SPI is one way to do that. Even if RI were not to
use triggers, we'd still want to reduce the per-statement costs.

WRT 2: Not using the generic per-row trigger framework for RI has significant
benefits too - checking multiple rows at once, deduplicating repeated
checks, reducing the per-row storage overhead ...

WRT 3: Fairly obviously improving the generic trigger code (more
efficient fetching of tuple versions, spilling etc) would have benefits
entirely independent of other RI improvements.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: design for parallel backup
Next
From: Jehan-Guillaume de Rorthais
Date:
Subject: Re: Remove non-fast promotion Re: Should we remove a fallbackpromotion? take 2