Tom Lane <t...@sss.pgh.pa.us> writes: > That argument is based on a completely evidence-free assumption, namely > that this patch would make your case faster. Executing the WHEN tests > is hardly going to be zero cost. It's not too hard to postulate cases > where implementing a filter this way would be *slower* than doing it > inside the trigger.
It's pretty often the case (IME) that calling a trigger is the only point in the session where you fire plpgsql, and that's a visible cost. Last time I had to measure it, it was 1ms per call. We were trying to optimize queries running in 3ms to 4ms, called more than 100 times a second (in parallel on multi core architecture, but still). The way I understand it, having the WHEN clause in CREATE TRIGGER would allow to filter out some interpreter initialisations. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
