Re: commit_delay, siblings

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: commit_delay, siblings
Date: 2005-06-29 21:38:28
Message-ID: 1120081108.3940.32.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2005-06-29 at 10:16 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Group commit is a well-documented technique for improving performance,
>
> The issue here is not "is group commit a good idea in the abstract?".
> It is "is the commit_delay implementation of the idea worth a dime?"
> ... and the evidence we have all points to the answer "NO". We should
> not let theoretical arguments blind us to this.

OK, sometimes I sound too theoretical when I do my World History of
RDBMS notes, :-) ... all I meant was "lets hold off till we've measured
it".

> > I would ask that we hold off on their execution, at least for the
> > complete 8.1 beta performance test cycle.
>
> I'm willing to wait a week while Tatsuo runs some fresh tests. I'm
> not willing to wait indefinitely for evidence that I'm privately
> certain will not be forthcoming.

I'm inclined to agree with you, but I see no need to move quickly. The
code's been there a while now.

Best Regards, Simon Riggs

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2005-06-29 21:41:11 Re: Open items
Previous Message David Fetter 2005-06-29 20:24:37 Re: Proposal: associative arrays for plpgsql (concept)