Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)

On 30 May 2012 13:24, Robert Haas <robertmhaas(at)gmail(dot)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