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
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
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 w
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
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
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 a
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.
>
> Ke
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.
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 b
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'
> > > 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
Bruce,
> > 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 eff
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 l
"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 mus
"Josh Berkus" 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 so far pre
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
th
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 mea
Tom Lane wrote:
Josh Berkus 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 use
Josh Berkus 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 useful values
f
20 matches
Mail list logo
