Re: [REVIEW] pg_last_xact_insert_timestamp
От | Simon Riggs |
---|---|
Тема | Re: [REVIEW] pg_last_xact_insert_timestamp |
Дата | |
Msg-id | CA+U5nMJDoz5g1=bUL2TURpNDeAwG25wWGpyfjadjS-irOPjduQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [REVIEW] pg_last_xact_insert_timestamp (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [REVIEW] pg_last_xact_insert_timestamp
|
Список | pgsql-hackers |
On Fri, Sep 30, 2011 at 8:11 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Sep 30, 2011 at 3:18 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> On Fri, Sep 30, 2011 at 3:24 AM, Kyotaro HORIGUCHI >> <horiguchi.kyotaro@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
В списке pgsql-hackers по дате отправления: