Re: Huge memory consumption on partitioned table with FKs
Corey Huinker <corey.huinker@gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>, keisuke.kuroda.3862@gmail.com, tatsuro.yamada.tf@nttcom.co.jp, pgsql-hackers@lists.postgresql.org, amitlangote09@gmail.com, tatsuhito.kasahara.rd@hco.ntt.co.jp
Date: 2020-12-01T03:25:30Z
Lists: pgsql-hackers
On Mon, Nov 30, 2020 at 9:48 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Corey Huinker <corey.huinker@gmail.com> writes: > > Given that we're already looking at these checks, I was wondering if this > > might be the time to consider implementing these checks by directly > > scanning the constraint index. > > Yeah, maybe. Certainly ri_triggers is putting a huge amount of effort > into working around the SPI/parser/planner layer, to not a lot of gain. > > However, it's not clear to me that that line of thought will work well > for the statement-level-trigger approach. In that case you might be > dealing with enough tuples to make a different plan advisable. > > regards, tom lane > Bypassing SPI would probably mean that we stay with row level triggers, and the cached query plan would go away, perhaps replaced by an already-looked-up-this-tuple hash sorta like what the cached nested loops effort is doing. I've been meaning to give this a try when I got some spare time. This may inspire me to try again.
Commits
-
Avoid creating duplicate cached plans for inherited FK constraints.
- c3ffe3486368 14.0 landed