Re: Do foreign key triggers get ran even if the key's value doesn't change?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Van Dyk <joe(at)tanga(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Do foreign key triggers get ran even if the key's value doesn't change?
Date: 2014-05-22 18:28:30
Message-ID: 4427.1400783310@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Joe Van Dyk <joe(at)tanga(dot)com> writes:
> On Thu, May 22, 2014 at 10:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> FWIW, I profiled this example (after cranking it up to 500 target tables
>> just because). AFAICT the primary component of the runtime increase is
>> query startup overhead associated with the increased number of target
>> tables.

> I must be missing something, there's only one table being updated?

Sorry, I wrote that a bit too hastily. The startup cost is actually
mainly driven by the number of triggers attached to the UPDATE's target
table. Specifically, what I'm seeing in oprofile is

samples % symbol name
32694 26.0730 MemoryContextStrdup
22608 18.0296 hash_search_with_hash_value
9979 7.9581 AllocSetAlloc
6919 5.5178 ri_KeysEqual
3910 3.1182 AllocSetCheck
3641 2.9036 AfterTriggerSaveEvent
2852 2.2744 MemoryContextAlloc
2778 2.2154 hash_any
2410 1.9219 ri_FetchConstraintInfo
2236 1.7832 hash_search
1906 1.5200 CopyTriggerDesc
1833 1.4618 hash_uint32
1817 1.4490 ri_NullCheck
1663 1.3262 RI_FKey_pk_upd_check_required
1338 1.0670 sentinel_ok
(nothing else above 1%)

The MemoryContextStrdup calls are all coming from CopyTriggerDesc, which
has to copy 1000 triggers' names in my test case; those calls presumably
also account for a good chunk of the AllocSetAlloc cycles. (It's possible
we could get rid of the TriggerDesc copy step in InitResultRelInfo, but it
seems rather nervous-making to do so, and it wouldn't really be worth
doing for examples with more realistic numbers of triggers.)

The hash_search calls are coming from a bunch of places, mostly relation
lookup and buffer cache lookup. There are some coming from ri_KeysEqual's
lookup of which comparison function to use to perform the IS NOT DISTINCT
FROM tests, but that doesn't seem to be a large component of that profile
item.

Anyway, it's hard to see how to improve this much, short of a major
redesign to avoid treating independent foreign key constraints as
independent triggers.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2014-05-22 18:46:32 Re: WAL bandwidth
Previous Message Torsten Förtsch 2014-05-22 18:25:09 WAL bandwidth