Re: Updating column on row update

From: silly8888 <silly8888(at)gmail(dot)com>
To: Thom Brown <thombrown(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, PGSQL Mailing List <pgsql-general(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updating column on row update
Date: 2009-11-23 00:22:21
Message-ID: 3c8f9f940911221622o1d8df075g4c40c1fa07d3a17f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> MySQL had the following syntax available:
> `updated_date` timestamp NOT NULL default CURRENT_TIMESTAMP on update
> CURRENT_TIMESTAMP

I wonder supporting this syntax would speed things up a little bit.
Here's a simple benchmark about the situation we are discussing here:

There are 2 tables:
CREATE TABLE t1 (n integer not null, mtime timestamp with time
zone not null);
CREATE TABLE t2 (n integer not null, mtime timestamp with time
zone not null);

and a trigger for the second one:
CREATE LANGUAGE plpgsql;
CREATE FUNCTION touch() RETURNS trigger AS $$
BEGIN
new.mtime := now();
RETURN new;
END;
$$ LANGUAGE 'plpgsql';
CREATE TRIGGER ttt_mtime BEFORE UPDATE or INSERT
ON t2 FOR EACH ROW EXECUTE PROCEDURE touch();

and here's the actual test:

test=> INSERT INTO t1(n,mtime) SELECT *, now() FROM generate_series(1,1000000);
INSERT 0 1000000
Time: 7382.313 ms
test=> INSERT INTO t2(n) SELECT * FROM generate_series(1,1000000);
INSERT 0 1000000
Time: 24541.088 ms

So, updating the column explicitly is 3.5 times faster than the
trigger. My guess is that in real life applications where tables have
"bigger" rows (more columns, data types other than integer), the
overhead of the trigger will be even smaller.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2009-11-23 00:33:32 Re: ERROR: aggregate function calls cannot be nested
Previous Message Jonathan Blitz 2009-11-23 00:14:04 ERROR: aggregate function calls cannot be nested

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Saito 2009-11-23 01:56:38 Re: forget patch win32.mak.
Previous Message David Fetter 2009-11-23 00:03:00 Re: operator exclusion constraints