On Fri, Sep 30, 2011 at 8:11 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Sep 30, 2011 at 3:18 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> On Fri, Sep 30, 2011 at 3:24 AM, Kyotaro HORIGUCHI >> <horiguchi.kyot...@oss.ntt.co.jp> wrote: >> >>> Ok, I send this patch to comitters. >> >> I repeat my objection to this patch. I'm very sorry I haven't been >> around much in last few weeks to keep up a dialogue about this and to >> make it clear how wrong I think this is. >> >> Adding something onto the main path of transaction commit is not good, >> especially when the only purpose of it is to run an occasional >> monitoring query for those people that use replication. Not everybody >> uses replication and even people that do use it don't need to run it >> so frequently that every single commit needs this. This is just bloat >> that we do not need and can also easily avoid. > > I think the overhead of this is so completely trivial that we > shouldn't be concerned about it. It's writing 12 bytes to shared > memory for each commit, without taking a lock, in a cache line that > should be minimally contended. We write plenty of other data to > shared memory on each commit, and that's nowhere close to being the > expensive part of committing a transaction. What's expensive is > fighting over WALInsertLock and ProcArrayLock and CLogControlLock, and > possibly waiting for the commit to be durably flushed to disk, and > maybe (at the margin) wrenching the cache lines in our PGPROC away > from whatever processor last stole them to do GetSnapshotData(). I > don't think that a couple of stores to uncontended shared memory are > going to make any difference.
If the feature could not be done another way, easily, I might agree. The point is it isn't necessary, useful or elegant to do it this way and *any* cycles added to mainline transactions need to have careful justification. And there really isn't any justification for doing things this way other than its the first way somebody thought of. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
