On Tue, Jan 31, 2012 at 3:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Tue, Jan 31, 2012 at 7:43 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com> wrote:
>
>> That seems like a pretty marginal gain. If you're bound by the speed of
>> fsyncs, this will reduce the latency by the time it takes to mark the clog,
>> which is tiny in comparison to all the other stuff that needs to happen,
>> like, flushing the WAL. And that's ignoring any additional overhead caused
>> by the signaling between processes. If you're bound by CPU capacity, this
>> doesn't help at all because it just moves the work around.
>
> We're not bound by CPU capacity. Latency is an issue, especially when
> contention drives it higher with occasional spikes.
>
> I expect this to have a good measurable impact, as well as a
> stabilising effect on the latency.
>
>> Anyway, this is quite different from the original goal and patch for group
>> commit, so can we please leave this for 9.3, and move on with the review of
>> pending 9.2 patches.
>
> Actually, there is very little change here from the original patch.
>
> But I would note that your own changes were also quite different, and
> had no noticeable gain. They were also based on a brand new and
> radical set of thoughts.
I think you're trying to muddy the waters. Heikki's implementation
was different than yours, and there are some things about it I'm not
100% thrilled with, but it's fundamentally the same concept. The new
idea you're describing here is something else entirely. Instead of
focusing on a technical critique of one implementation vs. another
(out of the three we have to choose from), you're looking at cramming
more optimizations into the implementation you prefer. I'm pretty
sure that Heikki's implementation could support that optimization,
too, if we actually want to do it that way. But there might be good
reasons not to do it that way: for example, every transaction commit
will have to bump the CLOG page LSN, which will delay setting hint
bits on other transactions on the page in cases where they can now be
set immediately. In any event, trying to slip it into the group
commit patch will serve only to prevent it from getting the separate
scrutiny which it doubtless deserves.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
