On 28 June 2012 18:57, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> FWIW, I think commit_delay is just fine. In practice, it's mostly commits
> that are affected, anyway. If we try to be more exact, I think it's just
> going to be more confusing to users.
You think it will confuse users less if we start telling them to use
something that we have a very long history of telling them not to use?
The docs say "it is rare that adding delay by increasing this
parameter will actually improve performance". The book PostgreSQL
high-performance says of commit_delay (and commit_siblings) "These are
not effective parameters to tune in most cases. It is extremely
difficult to show any speed-up by adjusting them, and quite easy to
slow every transaction down by tweaking them". Who would be brave
enough to use that in production? Unless you still think these
statements are true, and I don't see why you would, it seems like a
really bad judgement to not change the name.
Is anyone aware of a non-zero commit_delay in the wild today? I
personally am not.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
