Re: Sustained inserts per sec ... ? - Mailing list pgsql-performance

From Christopher Petrilli
Subject Re: Sustained inserts per sec ... ?
Date
Msg-id 59d991c405040421164aeea3fb@mail.gmail.com
Whole thread Raw
In response to Re: Sustained inserts per sec ... ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Sustained inserts per sec ... ?  ("Jim C. Nasby" <decibel@decibel.org>)
Re: Sustained inserts per sec ... ?  (Christopher Petrilli <petrilli@gmail.com>)
List pgsql-performance
On Apr 4, 2005 11:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <gsstark@mit.edu> writes:
> > All this is happening within a single transaction too, right? So there hasn't
> > been an fsync the entire time. It's entirely up to the kernel when to decide
> > to start writing data.
>
> No ... there's a commit every 500 records.  However, I think Chris said
> he was running with fsync off; so you're right that the kernel is at
> liberty to write stuff to disk when it feels like.  It could be that
> those outlier points are transactions that occurred in the middle of
> periodic syncer-driven mass writes.  Maybe fsync off is
> counterproductive for this situation?

Looking at preliminary results from running with shared_buffers at
16000, it seems this may be correct.  Performance was flatter for a
BIT longer, but slammed right into the wall and started hitting the
3-30 second range per COPY.  I've restarted the run, with fsync turned
on (fdatasync), and we'll see.

My fear is that it's some bizarre situation interacting with both
issues, and one that might not be solvable.  Does anyone else have
much experience with this sort of sustained COPY?

Chris
--
| Christopher Petrilli
| petrilli@gmail.com

pgsql-performance by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Compressing WAL
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Sustained inserts per sec ... ?