No, he's using either COPY or \COPY.
On Wed, Apr 20, 2005 at 12:34:27AM -0400, Greg Stark wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > What's really odd is that neither the CPU or the disk are being
> > hammered. The box appears to be pretty idle; the postgresql proces is
> > using 4
No, this is a single process. And there's known issues with context
storms on Xeons, so that might be what you're seeing.
On Tue, Apr 19, 2005 at 09:37:21PM -0700, Mischa Sandberg wrote:
> Quoting Tom Lane <[EMAIL PROTECTED]>:
>
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > A friend of
Quoting Tom Lane <[EMAIL PROTECTED]>:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > A friend of mine has an application where he's copying in 4000 rows at a
> > time into a table that has about 4M rows. Each row is 40-50 bytes. This
> > is taking 25 seconds on a dual PIII-1GHz with 1G of R
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> What's really odd is that neither the CPU or the disk are being
> hammered. The box appears to be pretty idle; the postgresql proces is
> using 4-5% CPU.
Is he committing every row? In that case you would see fairly low i/o
bandwidth usage because most
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> A friend of mine has an application where he's copying in 4000 rows at a
> time into a table that has about 4M rows. Each row is 40-50 bytes. This
> is taking 25 seconds on a dual PIII-1GHz with 1G of RAM and a 2 disk
> SATA mirror, running FBSD 4.10-sta
A friend of mine has an application where he's copying in 4000 rows at a
time into a table that has about 4M rows. Each row is 40-50 bytes. This
is taking 25 seconds on a dual PIII-1GHz with 1G of RAM and a 2 disk
SATA mirror, running FBSD 4.10-stable. There's one index on the table.
What's really
