Comments on: avoiding “empty” updates

By: Lecy

Lecy — Thu, 21 Jan 2010 16:54:19 +0000

Looks like I was a bit late on this one but it’s really a good post. I’m thinking about a reply on my site . . . Art Of War

By: </depesz> » Blog Archive » avoiding “empty” updates - part2

Mon, 21 Jan 2008 20:51:58 +0000

[...] time ago i wrote about potential (or not potential, depending on your situation) problem with updates which do not [...]

By: depesz

depesz — Wed, 02 Jan 2008 14:45:56 +0000

@Andrew Dunstan:
i will test it soon. i just have to finish some other tasks.

By: Andrew Dunstan

Andrew Dunstan — Wed, 02 Jan 2008 14:39:28 +0000

The penalty you are seeing above is almost certainly due to your using plpgsql for the trigger, and to using the row constructor to do field by field comparison. Try my C version, which compares using memcmp on the whole record in one hit, and you will see far better results.

By: depesz

depesz — Sun, 09 Sep 2007 12:06:01 +0000

@David Fetter:
true. in fact – i’m not fan of rules, so i dont know them well, but in this situation rule seems to be perfect as it works before any kind of triggers, and checks.

By: depesz

depesz — Sun, 09 Sep 2007 12:04:44 +0000

@Radim Kolar:
the fact that mysql does something doesn’t really prove anything. they also “do” commands that can work partially

and on the more serious side – i can see some uses to make empty updates. side-effects of update triggers are the first to think about.
plus – comparing (as Jeff mentioned) might be costly – remember that a single column might be up to 1gb of data! i definitely don’t want database to waste time with comparing this kind of data. and if i want – a trigger (or rule, as David showed) is really simple.

By: Jeff

Jeff — Sun, 09 Sep 2007 02:47:07 +0000

I agree that it could be done in the database. But in theory, comparing two records for every update could be costly, since PostgreSQL supports user-defined types, and out-of-line storage.

If you update based on a simple integer key, but another value in the same record is large and held in a separate physical location, the comparison could require reading additional data.

This could probably be optimized, but at least there are triggers if you really need them. I suspect that you could make the overhead of such a trigger negligible.

By: David Fetter

David Fetter — Sun, 09 Sep 2007 02:32:18 +0000

Another way to do this, using RULEs

CREATE RULE no_unchanging_updates AS
ON UPDATE
TO test
WHERE ROW(OLD.*) IS NOT DISTINCT FROM ROW(NEW.*)
DO INSTEAD NOTHING;

By: Radim Kolar

Radim Kolar — Sat, 08 Sep 2007 23:14:18 +0000

No, avoiding empty updates is work for DB server. MYSQL is doing that.