From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CommitDelay performance improvement |
Date: | 2001-02-23 23:40:59 |
Message-ID: | 200102232340.SAA05739@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-02-24 00:12:41 | Re: CommitDelay performance improvement |
Previous Message | Bruce Momjian | 2001-02-23 23:37:06 | Re: CommitDelay performance improvement |