User-Agent: Microsoft-Entourage/12.0.0.071130
Date: Mon, 04 Feb 2008 14:32:21 -0800
Subject: Re: Benchmark Data requested
From: Luke Lonergan <llonergan@greenplum.com>
To: Simon Riggs <simon@2ndquadrant.com>
CC: <pgsql-performance@postgresql.org>
Message-ID: <C3CCD275.52C9A%llonergan@greenplum.com>
Thread-Topic: [PERFORM] Benchmark Data requested
Thread-Index: Achnfc5QqJ3jaHTwwkaNoTmnBf/fDA==
In-Reply-To: <1202152061.4252.539.camel@ebony.site>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi Simon,

On 2/4/08 11:07 AM, "Simon Riggs" <simon@2ndquadrant.com> wrote:

>> "executor-executor" test and we/you should be sure that the PG planner has
>> generated the best possible plan.
> 
> If it doesn't then I'd regard that as a performance issue in itself.

Agreed, though that's two problems to investigate - I think the Monet/X100
stuff is clean in that it's a pure executor test.
 
> You maybe right, but I want to see where it hurts us the most.

You'll see :-)
 
>> The only way to cure this is to work on more rows than one at a time.
> 
> Do you have any results to show that's true, or are you just referring
> to the Cray paper? (Which used fixed length tuples and specific vector
> hardware).

No paper referenced, just inference from the results and their (and others)
conclusions about locality and re-use.  It's a similar enough situation to
scientific programming with vector processors versus cache based superscalar
that these are the right conclusions.  We've done the profiling to look at
cache misses and have some data to back it up as well.
 
> (With regard to benchmarks, I'd rather not download Monet at all. Helps
> avoid legal issues around did-you-look-at-the-code questions.)

None of us have looked at the code or downloaded it.  There are a number of
presentations out there for Monet/X100 to see what their results are.

- Luke