User-Agent: Microsoft-Entourage/11.1.0.040913
Date: Mon, 22 Aug 2005 10:46:33 -0700
Subject: Re: MemoryContextSwitchTo during table scan?
From: "Luke Lonergan" <llonergan@greenplum.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>,
	"Jignesh Shah" <jigneshk@hotmail.com>
Cc: pgsql-performance@postgresql.org
Message-ID: <BF2F5D89.CD30%llonergan@greenplum.com>
In-Reply-To: <16259.1124725300@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit

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