4 ms·
Oh I've been doing the `on conflict do update set id = EXCLUDED.id` thing for ages now. Thought the update would be no-op because nothing changed. Interesting.
by eknkc 2y ago
Oh I've been doing the `on conflict do update set id = EXCLUDED.id` thing for ages now. Thought the update would be no-op because nothing changed. Interesting.
- teget 2y agoIf you update a column that is not indexed you might get away with it without stressing the cleanup processes too much (vacuum and friends): https://www.postgresql.org/docs/current/storage-hot.html https://www.postgresql.org/docs/current/storage-hot.html
- arkh 2y ago> Thought the update would be no-op because nothing changed. You can use a specific trigger function just to prevent this: suppress_redundant_updates_trigger https://www.postgresql.org/docs/current/functions-trigger.html https://www.postgresql.org/docs/current/functions-trigger.ht... > The suppress_redundant_updates_trigger function, when applied as a row-level BEFORE UPDATE trigger, will prevent any update that does not actually change the data in the row from taking place. This overrides the normal behavior which always performs a physical row update regardless of whether or not the data has changed.
- agwa 2y agoI just tested that and the trigger causes the INSERT to return no rows if the row already exists. It basically turns the ON CONFLICT DO UPDATE into ON CONFLICT DO NOTHING.