Re: Experimental patch for inter-page delay in VACUUM - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Experimental patch for inter-page delay in VACUUM
Date
Msg-id 200311102222.hAAMMtP21920@candle.pha.pa.us
Whole thread Raw
In response to Re: Experimental patch for inter-page delay in VACUUM  (Jan Wieck <JanWieck@Yahoo.com>)
List pgsql-hackers
Jan Wieck wrote:
> Bruce Momjian wrote:
> 
> > Jan Wieck wrote:
> >> >> > If the background cleaner has to not just write() but write/fsync or
> >> >> > write/O_SYNC, it isn't going to be able to clean them fast enough.  It
> >> >> > creates a bottleneck where we didn't have one before.
> >> >> > 
> >> >> > We are trying to eliminate an I/O storm during checkpoint, but the
> >> >> > solutions seem to be making the non-checkpoint times slower.
> >> >> > 
> >> >> 
> >> >> It looks as if you're assuming that I am making the backends unable to 
> >> >> write on their own, so that they have to wait on the checkpointer. I 
> >> >> never said that.
> >> > 
> >> > Maybe I missed it but are those backend now doing write or write/fsync? 
> >> > If the former, that is fine.  If the later, it does seem slower than it
> >> > used to be.
> >> 
> >> In my all_performance.v4.diff they do write and the checkpointer does 
> >> write+sync.
> > 
> > Again, sorry to be confusing --- I might be good to try write/fsync from
> > the background writer if backends can do writes on their own too without
> > fsync.  The additional fsync from the background writer should reduce
> > disk writing during sync().  (The fsync should happen with the buffer
> > unlocked.)
> 
> No, you're not. But thank you for suggesting what I implemented.

OK, I did IM with Jan and I understand now --- he is using write/sync
for testing, but plans to allow several ways to force writes to disk
occasionally, probably defaulting to fsync on most platforms.  Backend
will still use write only, and a checkpoint will continue using sync().

The qustion still open is whether we can push most/all writes into the
background writer so we can use fsync/open instead of sync.  My point
has been that this might be hard to do with the same performance we have
now.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Ian Barwick
Date:
Subject: Re: PostgreSQL Backup problems with tsearch2
Next
From: Bruce Momjian
Date:
Subject: Re: [DOCS] Annotated release notes