On 7/18/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Christopher Petrilli <[EMAIL PROTECTED]> writes:
> > On 7/18/05, Tom Lane <[EMAIL PROTECTED]> 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...

So here's something odd I noticed:

20735 pgsql     16   0 20640  11m  10m R 48.0  1.2   4:09.65
20734 petrilli  25   0  8640 2108 1368 R 38.1  0.2   4:25.80 psql

The 47 and 38.1 are %CPU. Why would psql be burning so much CPU?  I've
got it attached ,via a pipe to another process that's driving it
(until I implement the protocol for COPY later).  I wouldn't think it
should be uing such a huge percentage of the CPU, no?

The Python script that's actually driving it is about 10% o the CPU,
which is just because it's generating the incoming data on the fly. 

I will give the CVS head a spin soon, but I wanted to formalize my
benchmarking more first.

| Christopher Petrilli

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to