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 postmaster 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. Thoughts? I will give the CVS head a spin soon, but I wanted to formalize my benchmarking more first. Chris -- | Christopher Petrilli | [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq