On 30 May 2012 13:24, Robert Haas <robertmh...@gmail.com> wrote: > Most of those actually do look like reasonable places to try to get > grouped flushing behavior, but: > > 1. It seems wrong to do it in xact_redo_commit_internal(). It won't > matter if commit_siblings>0 since there won't be any other backends > with transaction IDs anyway, but if commit_siblings==0 then we'll > sleep for no possible benefit. > > 2. Doing it in FlushBuffer() seems slightly iffy since we might be > sitting on a buffer lock. But maybe it's a win anyway, or just not > worth worrying about.
Typical values of commit_delay are usually a fraction of spinning rust latency, so I don't think that FlushBuffer() has any business really caring. These problems seem rather minor compared to the existing problems with the settings. As I've already outlined, I doubt it's possible to really remove the delays here without an over-engineered solution. In short, I suspect it isn't worth it. We must trust DBAs to set commit_siblings appropriately if they've set commit_delay. > Another thing to think about is that if we do this across the board > rather than just for commits, then commit_delay and commit_siblings > will really be totally misnamed - they really ought to be flush_delay > and flush_siblings at that point. Seems reasonable. It would also have the advantage of avoiding having the new implementation tarred with the same brush as commit_delay. -- 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
