That's on Greenplum latest.

We used this query to expose CPU heavy aggregation.

The 1GB overall TPCH size is chosen to fit into the RAM of a typical 
workstation/laptop with 2GB of RAM.  That ensures the time is spent in the CPU 
processing of the hashagg, which is what we'd like to measure here.

The PG performance will be different, but the measurement approach should be 
the same IMO.  The only suggestion to make it easier is to use 250MB scale 
factor, as we use four cores against 1GB.  The principal is the same.

- Luke

Msg is shrt cuz m on ma treo

 -----Original Message-----
From:   Simon Riggs [mailto:[EMAIL PROTECTED]
Sent:   Sunday, October 28, 2007 04:48 PM Eastern Standard Time
To:     CK.Tan
Cc:     Luke Lonergan; Kenneth Marshall;; [EMAIL 
Subject:        Re: [PATCHES] updated hash functions for postgresql v1

On Sun, 2007-10-28 at 13:19 -0700, CK Tan wrote:
> Hi, this query on TPCH 1G data gets about 5% improvement.

> select count (*) from (select l_orderkey, l_partkey, l_comment,
> count(l_tax) from lineitem group by 1, 2, 3) tmpt;

> On Oct 28, 2007, at 1:17 PM, Luke Lonergan wrote:
> > We just applied this and saw a 5 percent speedup on a hash
> > aggregation query with four colums in a 'group by' clause run
> > against a single TPC-H table (lineitem).
> > 
> > CK - can you post the query? 

Is this on Postgres or Greenplum?

That looks like quite a wide set of columns.

Sounds good though. Can we get any more measurements in?

  Simon Riggs

Reply via email to