X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 447DDDAF8D for ; Thu, 24 Nov 2005 05:11:41 -0400 (AST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 79720-05 for ; Thu, 24 Nov 2005 09:11:42 +0000 (GMT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from linda-1.paradise.net.nz (bm-1a.paradise.net.nz [203.96.152.180]) by svr1.postgresql.org (Postfix) with ESMTP id C419ED6EBC for ; Thu, 24 Nov 2005 05:11:38 -0400 (AST) Received: from smtp-2.paradise.net.nz (tclsnelbe2-src-nat-1 [203.96.152.177]) by linda-1.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IQG00E8WC7GS3@linda-1.paradise.net.nz> for pgsql-performance@postgresql.org; Thu, 24 Nov 2005 22:11:40 +1300 (NZDT) Received: from [192.168.1.11] (218-101-28-4.dsl.clear.net.nz [218.101.28.4]) by smtp-2.paradise.net.nz (Postfix) with ESMTP id 83A9D9AE7B0; Thu, 24 Nov 2005 22:11:38 +1300 (NZDT) Date: Thu, 24 Nov 2005 22:11:36 +1300 From: Mark Kirkwood Subject: Re: Hardware/OS recommendations for large databases ( In-reply-to: To: Luke Lonergan Cc: stange@rentec.com, Greg Stark , Dave Cramer , Joshua Marsh , pgsql-performance@postgresql.org Message-id: <438583C8.4050809@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051106) References: X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.222 required=5 tests=[AWL=0.222] X-Spam-Score: 0.222 X-Spam-Level: X-Archive-Number: 200511/484 X-Sequence-Number: 15741 Luke Lonergan wrote: > Mark, > > > It would be nice to put some tracers into the executor and see where the > time is going. I'm also curious about the impact of the new 8.1 virtual > tuples in reducing the executor overhead. In this case my bet's on the agg > node itself, what do you think? > Yeah - it's pretty clear that the count aggregate is fairly expensive wrt cpu - However, I am not sure if all agg nodes suffer this way (guess we could try a trivial aggregate that does nothing for all tuples bar the last and just reports the final value it sees). Cheers Mark