Andrew Dunstan wrote:
I don't follow what you're saying.
If an update is skipped by a trigger, nothing new is written to disk,
and there should be nothing to vacuum from it. That's why this trigger
can speed up certain update queries enormously.
OK I'll try again.
Suppose we do an update.
This will:
- write the new image and do the MVCC housekeeping
- logically lock the updated row
- fire update triggers
Suppose the pre-update trigger elides the update - ALL of the above is
removed.
Now, one of the objections to making it the default behaviour is that
the side effects (such as the lock and the trigger) might be desirable,
or at least that removing them is a change in behaviour.
I'm wondering whether it would be possible to remove the physical update
but retain the logical side effects,, so this argument about changed
semantics is removed, and the only issue is whether the cost of
identifying the noop update is worthwhile given the savings achieved,
which will be application dependent.
James
(I suspect that if you step back from the implementation of the SQL
engine as a series of procedural steps on rows - and think of it in
terms of relational set algebra, then it is entirely defensible to elide
such an update as a matter of course and that it SHOULD happen - but
then there is always fun and games around inserting duplicates too, and
I suspect most of us don't think in algebra terms)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
