From: | Christopher Petrilli <petrilli(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Vivek Khera <vivek(at)khera(dot)org>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Impact of checkpoint_segments under continual load conditions |
Date: | 2005-07-19 14:48:42 |
Message-ID: | 59d991c405071907482bb0689b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 7/18/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > The table has 15 columns, 5 indexes (character, inet and timestamp).
> > No foreign keys. The only other thing running on the machine was the
> > application actually DOING the benchmarking, written in Python
> > (psycopg), but it was, according to top, using less than 1% of the
> > CPU. It was just talking through a pipe to a psql prompt to do the
> > COPY.
>
> Sounds pretty plain-vanilla all right.
>
> Are you in a position to try the same benchmark against CVS tip?
> (The nightly snapshot tarball would be plenty close enough.) I'm
> just wondering if the old bgwriter behavior of locking down the
> bufmgr while it examined the ARC/2Q data structures is causing this...
Tom,
It looks like the CVS HEAD is definately "better," but not by a huge
amount. The only difference is I wasn't run autovacuum in the
background (default settings), but I don't think this explains it.
Here's a graph of the differences and density of behavior:
http://blog.amber.org/diagrams/pgsql_copy_803_cvs.png
I can provide the raw data. Each COPY was 500 rows. Note that fsync
is turned off here. Maybe it'd be more stable with it turned on?
Chris
--
| Christopher Petrilli
| petrilli(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-07-19 15:04:30 | Re: Impact of checkpoint_segments under continual load conditions |
Previous Message | Yves Vindevogel | 2005-07-19 13:38:36 | Re: Insert performance (OT?) |