Hi Junwang, On Fri, Mar 20, 2026 at 1:20 AM Junwang Zhao <[email protected]> wrote: > I squashed 0004 into 0003 so that each file can be committed independently. > I also runned pgindent for each file.
Thanks for that. Here's another version. In 0001, I noticed that the condition change in ri_HashCompareOp could be simplified further. Also improved the commentary surrounding that. I also updated the commit message to clarify parity with the SPI path. Updated the commit message of 0002 to talk about why caching the snapshot for the entire trigger firing cycle of a given constraint makes a trade off compared to the SPI path which retakes the snapshot for every row checked and could in principle avoid failure for FK rows whose corresponding PK row was added by a concurrently committed transaction, at least in the READ COMMITTED case. Updated the commit message of 0003 to clarify that it replaces ri_FastPathCheckCached() from 0002 with the BatchAdd/BatchFlush pair, and that the cached resources are used unchanged -- only the probing cadence changes from per-row to per-flush. Per-flush CCI is safe because all AFTER triggers for the buffered rows have already fired by flush time; a new test case is added to show that. Finally I added a short line at the end of each patch's commit message to mention the speedup observed at each stage. There are placeholders such as <commit-hash-0001> that I will replace by an actual commit hash before pushing. I will continue staring at these for any remaining issues before pushing them one-by-one at some point by early next week. Happy to hear any thoughts before I push. -- Thanks, Amit Langote
v9-0003-Batch-FK-rows-and-use-SK_SEARCHARRAY-for-fast-pat.patch
Description: Binary data
v9-0002-Cache-per-batch-resources-for-fast-path-foreign-k.patch
Description: Binary data
v9-0001-Add-fast-path-for-foreign-key-constraint-checks.patch
Description: Binary data
