Re: Concurrent COPY commands

------=_Part_6081_15155732.1215623233955
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

> Define low. 2 disks maxed out doing random I/O could show as little as 2
or
> 3 MB/sec in vmstat.

While the copy commands are not at 100% CPU it is about that low. It does
go
up at times, but not by much (maybe 5-7 MB/sec). Does a COPY command count
as random I/O if the data it's reading is actually a memory FIFO and it's
only reading data in for the current (not completed) transaction? The
disks
are completely dedicated to the database, so postgres is the only app
using
it.

> You say one CPU core is maxed out - what state is it mostly in at 100% -
> user, system, or wait?

I'll double-check, but I'm certain that it was user. The behavior didn't
seem to change when I changed the table layout either.

- Phillip

On Wed, Jul 9, 2008 at 9:45 AM, Alan Hodgson <ahodgson@[EMAIL PROTECTED]
> wrote:

> On Wednesday 09 July 2008, "Phillip Sitbon" <phillip@[EMAIL PROTECTED]
> wrote:
> > I only have two fast SATA drives on software RAID, but that really
isn't
> > the issue- while the copy commands are going, disk activity is
relatively
> > low.
>
> Define low. 2 disks maxed out doing random I/O could show as little as 2
or
> 3 MB/sec in vmstat.
>
> You say one CPU core is maxed out - what state is it mostly in at 100% -
> user, system, or wait?
>
>
> --
> Alan
>
> --
> Sent via pgsql-novice mailing list (pgsql-novice@[EMAIL PROTECTED]
)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-novice
>

------=_Part_6081_15155732.1215623233955
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

&gt; Define low. 2 disks maxed out doing random I/O could show as little
as 2 or<br>
&gt; 3 MB/sec in vmstat.<br><br>While the copy commands are not at 100%
CPU it is about that low. It does go up at times, but not by much (maybe
5-7 MB/sec). Does a COPY command count as random I/O if the data it&#39;s
reading is actually a memory FIFO and it&#39;s only reading data in for
the current (not completed) transaction? The disks are completely
dedicated to the database, so postgres is the only app using it.<br>
<br>&gt; You say one CPU core is maxed out - what state is it mostly in at
100% -<br>
&gt; user, system, or wait?<br><br>I&#39;ll double-check, but I&#39;m
certain that it was user. The behavior didn&#39;t seem to change when I
changed the table layout either.<br><br>- Phillip<br><br><div
class="gmail_quote">
On Wed, Jul 9, 2008 at 9:45 AM, Alan Hodgson &lt;<a
href="mailto:ahodgson@[EMAIL PROTECTED]
">ahodgson@[EMAIL PROTECTED]
>&gt;
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wednesday 09 July 2008, &quot;Phillip Sitbon&quot;
&lt;<a href="mailto:phillip@[EMAIL PROTECTED]
">phillip@[EMAIL PROTECTED]
>&gt;
wrote:<br>
&gt; I only have two fast SATA drives on software RAID, but that really
isn&#39;t<br>
&gt; the issue- while the copy commands are going, disk activity is
relatively<br>
&gt; low.<br>
<br>
</div>Define low. 2 disks maxed out doing random I/O could show as little
as 2 or<br>
3 MB/sec in vmstat.<br>
<br>
You say one CPU core is maxed out - what state is it mostly in at 100%
-<br>
user, system, or wait?<br>
<font color="#888888"><br>
<br>
--<br>
</font><div><div></div><div class="Wj3C7c">Alan<br>
<br>
--<br>
Sent via pgsql-novice mailing list (<a
href="mailto:pgsql-novice@[EMAIL PROTECTED]
">pgsql-novice@[EMAIL PROTECTED]
>)<br>
To make changes to your subscription:<br>
<a href="http://www.postgresql.org/mailpref/pgsql-novice"
target="_blank">http://www.postgresql.org/mailpref/pgsql-novice</a><br>
</div></div></blockquote></div><br>

------=_Part_6081_15155732.1215623233955--