On 31 May 2012 14:58, Robert Haas <robertmh...@gmail.com> wrote: > 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.
Yes, the fact that I wanted to get rid of commit_delay is well established - I called for its deprecation in a dedicated thread, and during my talk at pgCon. Bruce's confusion as to how that interacted with what I've been calling "new group commit" was actually what crystallised my position here: it is trying, for the most part, to do the same thing as new group commit, but in an entirely orthogonal way. Bruce's confusion actually reflected the confusion of the code. So I'm in a sense removing the overlap between commit_delay used to do but now but shouldn't try to do anymore (make commits coincide, giving good benchmark results) and what new group commit now does, while preserving commit_delay's ability to trade off latency for throughput. I didn't have an answer to the question of how we might continue to offer a throughput/latency trade-off to users before, but knew that with 9.2, commit_delay was totally ineffective anyway. The realisation that it could be made effective by working with rather than against new group commit changed my mind. > 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. The patch can be justified as a way of removing the tension between new group commit and commit_delay. Removing commit_delay would also do this, but then there'd be no way to make the aforementioned trade-off that we previously offered. I suspect that if it restored the peaks and valleys of commit_delay's changes to throughput in 9.1, over and above a new group commit baseline, this would be more readily accepted. I hope the patch isn't being punished for being effective. Yes, it does offer a large boost to performance, but that happens to be incidental, unlikely though that sounds. You've called this a clever idea. I actually don't agree. I was fairly surprised that no one noticed this earlier. It is rather obviously the case that a delay that hopes to maximise the batching of commits at the expense of latency should occur only in a single leader backend that will proceed with the flush for the batch, and not within each and every backend as it commits. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
