On Thu, May 31, 2012 at 8:38 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 31 May 2012 13:16, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, May 31, 2012 at 6:19 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Frankly, I think this whole thing should be pushed to 9.3. The
>> commit_delay and commit_siblings knobs suck, but they've sucked for a
>> long time, and it won't kill anybody to wait another release cycle to
>> fix them. We have plenty of more important things queued up for 9.3
>> already, and I don't believe there's any compelling reason to think
>> that this particular thing needs preferential treatment.
>
> Why do you think that? Those knobs are now quite ineffective, though
> we never even considered that when the group commit delay patch was
> committed. The entire body of research and commentary that exists on
> commit_delay has been invalidated for 9.2. If that isn't something
> that needs to be addressed before release, I don't know what is. The
> fact that the patch can sometimes double transaction throughput for an
> absolutely trivial change, moving 2 lines of code, is also a good
> reason to not bump this for another year.
Fixing regressions before release is essential; improving performance
is not - especially when the improvement relates to a little-used
feature that you were proposing to get rid of two weeks ago. It can't
simultaneously be so unimportant that we should remove it altogether
and so important that it's must-fix-before-release, and if one test
can completely overturn your view of which category this falls into,
that seems like a reason for taking some more time to think it over
and, perhaps, run more tests. We don't have a lot of latitude to
maneuver at this point - anything we do now is going to go straight
out into the wild. Caution is appropriate.
However, rather than arguing about it, let's see if anyone else has an opinion.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
