From: | Mike Noordermeer <mike(at)normi(dot)net> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Dirty buffers with suppress_redundant_updates_trigger |
Date: | 2020-09-14 05:53:08 |
Message-ID: | CAF0ozquHAvsWdr1XYJ8cP-Gohzt-CuZHnatdUpwCoWm7UrupXg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias Apitz | 2020-09-14 06:09:44 | Why SELECT COUNT(*) takes so long? |
Previous Message | nandha kumar | 2020-09-14 05:17:10 | Reg:CHARSET_COVERSION_LATIN_TO_UTF8 |