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.
Msg is shrt cuz m on ma treo
From: Simon Riggs [mailto:[EMAIL PROTECTED]
Sent: Sunday, October 28, 2007 04:48 PM Eastern Standard Time
Cc: Luke Lonergan; Kenneth Marshall; email@example.com; [EMAIL
PROTECTED]; [EMAIL PROTECTED]
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?