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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)
Date: 2012-05-29 16:10:41
Message-ID: CA+TgmobFP0bp3FAfipNa2pzyua9GUWu99o5-V-Ay7dAhPmFKfA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 28, 2012 at 9:18 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> The attached very simple patch moves the commit_delay +
> commit_siblings sleep into XLogFlush, where the leader alone sleeps.
> This appears to be a much more effective site for a delay.

This is a clever idea, but I think it needs some fine-tuning: as
written, this will sleep for any flush, not just a flush of a commit
record. One idea might be to add a flag to XLogFlush indicating
whether a commit-delay sleep is permissible. Callers other than
RecordTransactionCommit() could pass false; RecordTransactionCommit()
could pass true.

The comments need some updating, too.

Like Heikki, I find the test results that you posted pretty hard to
understand. This is sort of a general beef I have with pgbench-tools:
there are no explanations anywhere about what the graphs actually
mean. The first three graphs seem fairly useless, and the third one
doesn't even appear to contain any data. The fourth and fifth graphs
seem like the most useful part of the output, but the lack of an
explanation of what's being graphed really hinders understanding.
Apparently, the fourth graph is TPS vs. scale factor (at an
unspecified number of clients) and the fifth graph is TPS vs. clients
(at an unspecified scale factor). Maybe we're just averaging across
the unspecified parameter in each case, but if so that doesn't seem
very useful.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-05-29 16:22:18 Re: Bogus nestloop rows estimate in 8.4.7
Previous Message Tom Lane 2012-05-29 15:52:22 Re: pg_dump and thousands of schemas