On Wed, Mar 20, 2013 at 09:50:55PM +0000, Peter Geoghegan wrote: > The fact is that whichever backend happens to end up becoming the > group commit leader from one XLogFlush() call to the next is, for all > practical purposes, unpredictable. You cannot reasonably hope to avoid > a delay within an important transaction that needs to prioritize > keeping its own latency low over total cluster throughput. If you set > commit_delay to 0 in your important transaction with this is mind, > your chances of becoming the group commit leader and avoiding the > delay are slim to almost none. Much more often than not, the important > transaction will end up becoming a group commit follower, and it'll > still spend a significant fraction of commit_delay (about 1/2, on > average) blocking on LWLockAcquireOrWait().
I acknowledge that "SET commit_delay = 0" does not usefully reduce latency for a transaction running on a system subject to a uniform, high commit rate. It is useful for other things. Suppose you have a low-concurrency system with commit_delay=0 in postgresql.conf, but you occasionally spin up a parallel task that benefits from nonzero commit_delay. Changing commit_delay in the task's sessions is a decent approximation of, and more convenient than, temporarily modifying postgresql.conf. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
