Re: CommitDelay performance improvement - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: CommitDelay performance improvement
Date
Msg-id 200102232340.SAA05739@candle.pha.pa.us
Whole thread Raw
In response to Re: CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CommitDelay performance improvement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > It could be tough.  Imagine the delay increasing to 3 seconds?  Seems
> > there has to be an upper bound on the sleep.  The more you delay, the
> > more likely you will be to find someone to fsync you.
> 
> Good point, and an excellent illustration of the fact that
> self-adjusting algorithms aren't that easy to get right the first
> time ;-)

I see.  I am concerned that anything done to 7.1 at this point may cause
problems with performance under certain circumstances.  Let's see what
the new code shows our testers.

> 
> > Are we waking processes up after we have fsync()'ed them?
> 
> Not at the moment.  That would be another good mechanism to investigate
> for 7.2; but right now there's no infrastructure that would allow a
> backend to discover which other ones were sleeping for fsync.

Can we put the backends to sleep waiting for a lock, and have them wake
up later?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: CommitDelay performance improvement
Next
From: Tom Lane
Date:
Subject: Re: CommitDelay performance improvement