Subject: Re: Benchmark Data requested
From: Simon Riggs <simon@2ndquadrant.com>
To: Luke Lonergan <llonergan@greenplum.com>
Cc: pgsql-performance@postgresql.org
In-Reply-To: <C3CC9DD5.52BD9%llonergan@greenplum.com>
References: <C3CC9DD5.52BD9%llonergan@greenplum.com>
Content-Type: text/plain
Date: Mon, 04 Feb 2008 19:07:41 +0000
Message-Id: <1202152061.4252.539.camel@ebony.site>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2008-02-04 at 10:47 -0800, Luke Lonergan wrote:

> Note that MonetDB/X100 does not have a SQL optimizer, they ran raw
> hand-coded plans.  As a consequence, these comparisons should be taken as an
> "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.

> That said, we've already done the comparisons internally and they've got a
> good point to make about L2 cache use and removal of unnecessary
> abstractions in the executor.  We've been aware of this since 2005/6 and
> have been slowly working these ideas into our/PG executor.
>
> Bottom line: it's a good thing to work to get close to the X100/Monet
> executor with a more general purpose DB.  PG is a looong way from being
> comparable, mostly due to poor L2 D-cache locality and I-cache thrashing in
> the executor.  

You maybe right, but I want to see where it hurts us the most.

> 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).

(With regard to benchmarks, I'd rather not download Monet at all. Helps
avoid legal issues around did-you-look-at-the-code questions.)

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com