To: Christopher Petrilli <petrilli@gmail.com>
Cc: Vivek Khera <vivek@khera.org>, pgsql-performance@postgresql.org
Subject: Re: Impact of checkpoint_segments under continual load conditions 
In-reply-to: <59d991c405071812342e290f57@mail.gmail.com> 
References: <59d991c4050717100874c08a86@mail.gmail.com>
	<A50B8A1F-71A1-4F63-A5F4-1AA58F89557D@khera.org>
	<59d991c405071811457ccdd3f1@mail.gmail.com>
	<16394.1121715156@sss.pgh.pa.us>
	<59d991c405071812342e290f57@mail.gmail.com>
Comments: In-reply-to Christopher Petrilli <petrilli@gmail.com>
	message dated "Mon, 18 Jul 2005 15:34:57 -0400"
Date: Mon, 18 Jul 2005 16:32:23 -0400
Message-ID: <16794.1121718743@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Christopher Petrilli <petrilli@gmail.com> writes:
> On 7/18/05, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I have no idea at all what's causing the sudden falloff in performance
>> after about 10000 iterations.  COPY per se ought to be about a
>> constant-time operation, since APPEND is (or should be) constant-time.
>> What indexes, foreign keys, etc do you have on this table?  What else
>> was going on at the time?

> 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...

			regards, tom lane