From: Luke Lonergan <llonergan@greenplum.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Jignesh Shah <jigneshk@hotmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: MemoryContextSwitchTo during table scan?
Date: Mon, 22 Aug 2005 10:46:33 -0700
Message-ID: <BF2F5D89.CD30%llonergan@greenplum.com> (raw)
In-Reply-To: <16259.1124725300@sss.pgh.pa.us>
Tom,
On 8/22/05 8:41 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>> MemoryContextSwitchTo and LockBuffer itself takes 15% of the total time of
>> the query. I was expecting "read" to be the slowest part (biggest component)
>> but it was way down in the 0.4% level.
>
> You do know that gprof counts only CPU time, and only user-space CPU
> time at that? read() isn't going to show up at all. It's fairly likely
> that your test case is I/O bound and that worrying about CPU efficiency
> for it is a waste of time anyway.
He's running DTRACE, a CPU profiler that uses hardware performance
registers, not gprof. BTW, if you statically link your app, you get
profiling information for system calls with gprof.
Jignesh has been analyzing PG for quite a while, there are definite issues
with CPU consuming functions in the data path IMO. This result he reported
is one of them on Solaris 10, and possibly on other platforms.
We are limited to about 130MB/s of I/O throughput for sequential scan on
platforms that can do 240MB/s of sequential 8k block I/O. Though I haven't
profiled seqscan, I'd look at Jignesh's results carefully because they
correlate with our experience.
- Luke
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: llonergan@greenplum.com, tgl@sss.pgh.pa.us, jigneshk@hotmail.com
Subject: Re: MemoryContextSwitchTo during table scan?
In-Reply-To: <BF2F5D89.CD30%llonergan@greenplum.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