On Mon, 2005-01-24 at 12:12 +0100, Manfred Koizar wrote:
On Fri, 21 Jan 2005 23:52:51 +, Simon Riggs [EMAIL PROTECTED]
wrote:
Currently, we have group commit functionality via GUC parameters
commit_delay
and commit_siblings
And since 7.3 we have ganged WAL writes (c.f. the thread
Simon Riggs [EMAIL PROTECTED] writes:
So: objective: measure whether commit_delay is worth keeping.
My guess is that it would only be useful in highly specialized cases,
but since the code is so small and localized, it's hard to argue that
there's any great value in ripping it out either.
On Fri, 21 Jan 2005 23:52:51 +, Simon Riggs [EMAIL PROTECTED]
wrote:
Currently, we have group commit functionality via GUC parameters
commit_delay
andcommit_siblings
And since 7.3 we have ganged WAL writes (c.f. the thread starting at
On Sat, 2005-01-22 at 00:18 -0600, Jim C. Nasby wrote:
1) I'm in favor of autotuning anything possible.
2) In addition to turning group_commit on and off, what about also
adjusting the commit delay, based on statistics of recent commits? It
might require a slightly larger sample set (maybe the
On Sat, Jan 22, 2005 at 08:47:37AM +, Simon Riggs wrote:
On Sat, 2005-01-22 at 00:18 -0600, Jim C. Nasby wrote:
1) I'm in favor of autotuning anything possible.
2) In addition to turning group_commit on and off, what about also
adjusting the commit delay, based on statistics of recent
Simon Riggs [EMAIL PROTECTED] writes:
Each transaction commit gets the current time(NULL) immediately before
it commits.
time() has 1 second resolution and ergo is utterly useless for this.
gettimeofday() may have sufficient resolution, but the resolution is
not specified anywhere.
Currently, we have group commit functionality via GUC parameters
commit_delay
and commit_siblings
Group commit is either off or on. Since we do not have a log writer
daemon, there is no way to know whether that is optimal. There is
research to show that setting group commit on when it
1) I'm in favor of autotuning anything possible.
2) In addition to turning group_commit on and off, what about also
adjusting the commit delay, based on statistics of recent commits? It
might require a slightly larger sample set (maybe the last 100 commits),
but it seems it would provide more
