On 11/19/2013 12:45 AM, Noah Misch wrote:
On Fri, Nov 15, 2013 at 01:01:48PM -0500, Andrew Dunstan wrote:
The triggers don't fire if there is no real XID, so only actual data
changes should cause the trigger to fire.
What's the advantage of this provision? Without it, an individual trigger
could make the same check and drop out quickly. A trigger not wanting it
can't so easily work around its presence, though. Heretofore, skipping XID
assignment has been an implementation detail that improves performance without
otherwise calling user attention to itself. This provision would make the
decision to acquire an XID (where optional) affect application behavior.
Mainly speed. How is the trigger (especially if not written in C) going
to check the same thing?
Conventional triggers don't fire except on data changing events, so this
seemed consistent with that.
Perhaps my understanding of when XIDs are acquired is insufficient. When
exactly is it optional?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
