From: | Jim Nasby <jnasby(at)pervasive(dot)com> |
---|---|
To: | Kris Kennaway <kris(at)obsecurity(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: postgresql and process titles |
Date: | 2006-06-17 17:33:09 |
Message-ID: | 3E9F8629-1EFE-4790-A885-D84C22286385@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun 13, 2006, at 9:42 PM, Kris Kennaway wrote:
>> BTW, there's another FBSD performance odditiy I've run across.
>> Running
>>
>> pg_dump -t email_contrib -COx stats | bzip2 > ec.sql.bz2 &
>>
>> which dumps the email_contrib table to bzip2 then to disk, the OS
>> won't use more than 1 CPU on an SMP system... unless the data is
>> cached. According to both gstat and systat -v, the system isn't I/O
>> bound; both are reporting the RAID10 with that table on it as only
>> about 10% busy. If I let that command run for a bit then cancel it
>> and re-start it so that the beginning of that table is in cache, it
>> will use one entire CPU for bzip2, which is what I'd expect to
>> happen.
>
> Hmm, odd..maybe something with the scheduler. I'd need access to a
> test case to be able to figure it out though.
well, pg_dump of any sizeable database piped through bzip2 or gzip
should show this. Try:
pg_dump large_database | bzip2 > databasedump.sql.bz2
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | paolo romano | 2006-06-17 17:37:18 | Re: MultiXacts & WAL |
Previous Message | Jim Nasby | 2006-06-17 17:30:35 | Re: postgresql and process titles |