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 RAM and a 2 disk 
> > SATA mirror, running FBSD 4.10-stable. There's one index on the table. 
> If there's no hidden costs such as foreign key checks, that does seem 
> pretty dang slow. 
> > 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. 
This sounds EXACTLY like my problem, if you make the box to a Xeon 2.4GHz, 2GB 
RAM ... with two SCSI drives (xlog and base); loading 10K rows of about 200 
bytes each; takes about 20 secs at the best, and much longer at the worst. By 
any chance does your friend have several client machines/processes trying to 
mass-load rows at the same time? Or at least some other processes updating 
that table in a bulkish way? What I get is low diskio, low cpu, even low 
context-switches ... and I'm betting he should take a look at pg_locks. For my 
own problem, I gather that an exclusive lock is necessary while updating 
indexes and heap, and the multiple processes doing the update can make that 
Anyway, have your friend check pg_locks. 
"Dreams come true, not free." -- S.Sondheim, ITW 

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to