From: Mladen Gogala <mladen.gogala@vmsinfo.com>
To: James Cloos <cloos@jhcloos.com>
Cc: Royce Ausburn <royce@inomial.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: CPU bound
Date: Mon, 20 Dec 2010 01:47:30 -0500
Message-ID: <4D0EFC02.7040004@vmsinfo.com> (raw)
In-Reply-To: <m38vzl6z17.fsf@jhcloos.com>
References: <F13DEE85-D114-4761-AD4D-924F1A741ACC@inomial.com>
<m38vzl6z17.fsf@jhcloos.com>
On 12/19/2010 7:57 PM, James Cloos wrote:
>>>>>> "RA" == Royce Ausburn<royce@inomial.com> writes:
> RA> I notice that when restoring a DB on a laptop with an SDD,
> RA> typically postgres is maxing out a CPU - even during a COPY.
>
> The time the CPUs spend waiting on system RAM shows up as CPU
> time, not as Wait time. It could be just that the SSD is fast
> enough that the RAM is now the bottleneck, although parsing
> and text<=>binary conversions (especially for integers, reals
> and anything stored as an integer) also can be CPU-intensive.
>
> -JimC
Good time accounting is the most compelling reason for having a wait
event interface, like Oracle. Without the wait event interface, one
cannot really tell where the time is spent, at least not without
profiling the database code, which is not an option for a production
database.
--
Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
www.vmsinfo.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mladen.gogala@vmsinfo.com, cloos@jhcloos.com, royce@inomial.com
Subject: Re: CPU bound
In-Reply-To: <4D0EFC02.7040004@vmsinfo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox