Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c) - Mailing list pgsql-hackers

From Alfred Perlstein
Subject Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Date
Msg-id 20001116132754.M830@fw.wintelcom.net
Whole thread Raw
In response to Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
* Bruce Momjian <pgman@candle.pha.pa.us> [001116 12:31] wrote:
> > > In OS kernel design, you try to avoid process herding bottlenecks. 
> > > Here, we want them herded, and giving up the CPU may be the best way to
> > > do it.
> > 
> > Yes, but if everyone yeilds you're back where you started, and with
> > 128 or more backends do you really want to cause possibly that many
> > context switches per fsync?
> 
> You are going to kernel call/yield anyway to fsync, so why not try and
> if someone does the fsync, we don't need to do it.  I am suggesting
> re-checking the need for fsync after the return from sleep(0).

It might make more sense to keep a private copy of the last time
the file was modified per-backend by that particular backend and
a timestamp of the last fsync shared globally so one can forgo the
fsync if "it hasn't been dirtied by me since the last fsync"

This would provide a rendevous point for the fsync call although
cost more as one would need to periodically call gettimeofday to
set the modified by me timestamp as well as the post-fsync shared
timestamp.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."


pgsql-hackers by date:

Previous
From: Alfred Perlstein
Date:
Subject: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Next
From: "Mikheev, Vadim"
Date:
Subject: RE: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)