X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 08B5A9DCB94 for ; Tue, 7 Mar 2006 13:19:02 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 71030-10 for ; Tue, 7 Mar 2006 13:19:00 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from exchange.g2switchworks.com (mail.g2switchworks.com [63.87.162.25]) by postgresql.org (Postfix) with ESMTP id 90C689DCC05 for ; Tue, 7 Mar 2006 13:18:59 -0400 (AST) Received: from 10.10.1.37 ([10.10.1.37]) by exchange.g2switchworks.com ([10.10.1.2]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Mar 2006 17:18:59 +0000 Received: from state.g2switchworks.com by mail.g2switchworks.com; 07 Mar 2006 11:18:59 -0600 Subject: Re: firebird X postgresql 8.1.2 windows, performance From: Scott Marlowe To: Alvaro Herrera Cc: andremachado , pgsql-performance@postgresql.org In-Reply-To: <20060307171514.GE6748@surnet.cl> References: <20060307162842.M37264@techforce.com.br> <1141751333.18820.172.camel@state.g2switchworks.com> <20060307171514.GE6748@surnet.cl> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1141751939.18820.174.camel@state.g2switchworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Tue, 07 Mar 2006 11:18:59 -0600 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.15 required=5 tests=[AWL=0.149, UNPARSEABLE_RELAY=0.001] X-Spam-Score: 0.15 X-Spam-Level: X-Archive-Number: 200603/64 X-Sequence-Number: 17501 On Tue, 2006-03-07 at 11:15, Alvaro Herrera wrote: > Scott Marlowe wrote: > > > Lastly, I noticed that after you clusters on all your indexes, the query > > planner switched from a merge join to a hash join, and it was slower. > > You might wanna try turning off hash joins for a quick test to see if > > merge joins are any faster. > > Anyway please note that clustering "all indexes" does not really make > sense. You can cluster only on one index. If you cluster on another, > then the first clustering will be lost. Better make sure to cluster on > the one index where it makes the most difference. Note that I was referring to his clustering on an index for each table. I.e. not on every single index. but he clustered on four tables / indexes at once, so that was what I was referring to. Sorry for any confusion there. So, do you see any obvious, low hanging fruit here?