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
