Reverse the search order in afterTriggerAddEvent(). When scanning existing AfterTriggerSharedData records in search of a match to the event being queued, we were examining the records from oldest to newest. But it makes more sense to do the opposite. The newest record is likely to be from the current query, while the oldest is likely to be from some previous command in the same transaction, which will likely have different details.
There aren't expected to be very many active AfterTriggerSharedData records at once, so that this change is unlikely to make any spectacular difference. Still, having added a nontrivially-expensive bms_equal call to this loop yesterday, I feel a need to shave cycles where possible. Discussion: https://postgr.es/m/4166712.1737583...@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/7921927bbb9d4a80ced9283b27c26eedb638f555 Modified Files -------------- src/backend/commands/trigger.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
