From: | Christopher Petrilli <petrilli(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PFC <lists(at)boutiquenumerique(dot)com>, 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 18:48:54 |
Message-ID: | 59d991c40507191148e6f9ec5@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 7/19/05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Christopher Petrilli <petrilli(at)gmail(dot)com> writes:
> >> Are you sure the backend is reading directly from the file, and not
> >> through psql? (\copy, or COPY FROM STDIN, would go through psql.)
>
> > The exact command is:
> > COPY test (columnlist...) FROM '/tmp/loadfile';
>
> I tried to replicate this by putting a ton of COPY commands like that
> into a file and doing "psql -f file ...". I don't see more than about
> 0.3% CPU going to psql. So there's something funny about your test
> conditions. How *exactly* are you invoking psql?
It is a subprocess of a Python process, driven using a pexpect
interchange. I send the COPY command, then wait for the '=#' to come
back.
Chris
--
| Christopher Petrilli
| petrilli(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-07-19 18:53:13 | Re: Impact of checkpoint_segments under continual load conditions |
Previous Message | Oliver Crosby | 2005-07-19 18:44:26 | Re: Looking for tips |