So it seems that when before triggers are handled, a SELECT FOR UPDATE
row-level lock is taken before the triggers are run. This causes a
write to the heap, as row-level locks are stored on-heap. This has the
unfortunate effect that suppress_redundant_updates_trigger() is not
able to prevent all writes to the heap.
I do not yet understand why these locks are taken in this case, and
not when I compare the fields in the UPDATE WHERE-clause, but that may
have something to do with transactional guarantees, or some other
tradeoffs during development.
If anyone has a brilliant idea on how to improve this situation,
please let me know. Otherwise I guess I will have to resort to
comparing all data values, either manually or in the WHERE clause, to
prevent the data loads from flooding the WAL.
Kind regards,
Mike