Hi,
Simon Riggs [EMAIL PROTECTED] 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
On Wed, 2005-06-22 at 11:11 -0700, Josh Berkus wrote:
Hans, Tom,
We have done extensive testing some time ago.
We could not see any difference on any platform we have tested (AIX,
Linux, Solaris). I don't think that there is one at all - at least not
on common systems.
Keen then.
Simon Riggs wrote:
Group commit is a well-documented technique for improving performance,
but the gains only show themselves on very busy systems. It is possible
in earlier testing any apparent value was actually hidden by the
BufMgrLock issues we have now resolved in 8.1. We now see XLogInsert
Simon Riggs wrote:
On Wed, 2005-06-22 at 11:11 -0700, Josh Berkus wrote:
Hans, Tom,
We have done extensive testing some time ago.
We could not see any difference on any platform we have tested (AIX,
Linux, Solaris). I don't think that there is one at all - at least not
on common
Simon Riggs [EMAIL PROTECTED] 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
On Wed, Jun 29, 2005 at 08:14:36AM +0100, Simon Riggs wrote:
Group commit is a well-documented technique for improving performance,
but the gains only show themselves on very busy systems. It is possible
in earlier testing any apparent value was actually hidden by the
BufMgrLock issues we
On Wed, 2005-06-29 at 10:16 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] 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
Just a warning, because I might bring it up after feature freeze.
If we yank them ( and I agree) I think we have to do it before feature
freeze.
I believe that we have consensus to yank them. Hans says that he did
extensive testing back as far as 7.4 and the options had no effect.
Tatsuo Ishii [EMAIL PROTECTED] writes:
If we yank them ( and I agree) I think we have to do it before feature
freeze.
I believe that we have consensus to yank them. Hans says that he did
extensive testing back as far as 7.4 and the options had no effect.
My opinion is, we'd better test
On Tue, Jun 28, 2005 at 10:35:43AM -0400, Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
If we yank them ( and I agree) I think we have to do it before feature
freeze.
I believe that we have consensus to yank them. Hans says that he did
extensive testing back as far as 7.4
Tom,
Incidentally, I have tests in the queue. It's just that the STP has been
very unreliable for the last month so I've not been able to get definitive
test results.
More important than commit_*, is, of course the WAL/CRC stuff for
checkpoint cost, which I'm also getting impatient to test.
Josh Berkus wrote:
Hackers:
I've been trying to get a test result for 8.1 that shows that we can
eliminate
commit_delay and commit_siblings, as I believe that these settings no longer
have any real effect on performance. However, the checkpointing performance
issues have so far
Tom Lane [EMAIL PROTECTED] writes
together with some kind of IPC to waken backends once xlog was flushed
past the point they needed. (Designing that is the hard part.)
I think we could use ProcSendSignal()/ProcWaitForSignal() mechanism to cope
with the problem, because they won't lost any
Hackers:
I've been trying to get a test result for 8.1 that shows that we can eliminate
commit_delay and commit_siblings, as I believe that these settings no longer
have any real effect on performance. However, the checkpointing performance
issues have so far prevented me from getting a good
Josh Berkus josh@agliodbs.com writes:
I've been trying to get a test result for 8.1 that shows that we can
eliminate
commit_delay and commit_siblings, as I believe that these settings no longer
have any real effect on performance.
I don't think they ever did :-(. The theory is good, but
Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
I've been trying to get a test result for 8.1 that shows that we can eliminate
commit_delay and commit_siblings, as I believe that these settings no longer
have any real effect on performance.
I don't think they ever did :-(. The
Hans, Tom,
We have done extensive testing some time ago.
We could not see any difference on any platform we have tested (AIX,
Linux, Solaris). I don't think that there is one at all - at least not
on common systems.
Keen then. Any objections to removing the GUC? We desperately need means
Hans-Jürgen Schönig [EMAIL PROTECTED] writes:
The theory is good, but useful values for commit_delay would probably be
under a millisecond, and there isn't any portable way to sleep for such
short periods.
Just because there's no portable way to be sure it'll work doesn't mean
there's no
Josh Berkus josh@agliodbs.com writes
Hackers:
I've been trying to get a test result for 8.1 that shows that we can
eliminate
commit_delay and commit_siblings, as I believe that these settings no
longer
have any real effect on performance. However, the checkpointing
performance
issues have
Qingqing Zhou [EMAIL PROTECTED] writes:
Would commit_delay/commit_siblings helps or we need a
background xlog writer and notify us the completion of xlogflush is better
(so we don't compete for this lock)?
The existing bgwriter already does a certain amount of xlog flushing
(since it must
20 matches
Mail list logo
