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:simon@2ndquadrant.com]
Sent: Sunday, October 28, 2007 04:48 PM Eastern Standard Time
To: CK.Tan
Cc: Luke Lonergan; Kenneth Marshall; pgsql-patches@postgresql.org; twraney@comcast.net; neilc@samurai.com
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
2ndQuadrant http://www.2ndQuadrant.com