X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 75A29529C2 for ; Sat, 2 Jul 2005 10:44:19 -0300 (ADT) 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 18485-04 for ; Sat, 2 Jul 2005 13:44:10 +0000 (GMT) Received: from mail.baymountain.com (mail.baymountain.com [8.7.96.19]) by svr1.postgresql.org (Postfix) with SMTP id C2014529D8 for ; Sat, 2 Jul 2005 10:44:08 -0300 (ADT) Received: (qmail 23726 invoked by uid 504); 2 Jul 2005 13:44:11 -0000 Received: from emil@baymountain.com by mail.baymountain.com by uid 501 with qmail-scanner-1.16 (spamassassin: 2.53. Clear:SA:0(0.0/7.0):. Processed in 0.245709 secs); 02 Jul 2005 13:44:11 -0000 Received: from unknown (HELO briggspack.com) (emil@briggspack.com@24.211.148.77) by mail.baymountain.com with SMTP; 2 Jul 2005 13:44:11 -0000 From: Emil Briggs Reply-To: emil@baymountain.com Organization: Baymountain, Inc. To: John A Meinel Subject: Re: Planner constants for RAM resident databases Date: Sat, 2 Jul 2005 09:44:07 -0400 User-Agent: KMail/1.7.1 Cc: Postgresql Performance References: <200507012159.39041.emil@baymountain.com> <200507012311.37942.emil@baymountain.com> <42C606AA.8060406@arbash-meinel.com> In-Reply-To: <42C606AA.8060406@arbash-meinel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507020944.07339.emil@baymountain.com> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.038 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200507/14 X-Sequence-Number: 13255 > When you do "explain analyze" of a query that you have difficulties > with, how are the planner's estimates. Are the estimated number of rows > about equal to the actual number of rows? Some of them are pretty far off. For example -> Merge Left Join (cost=9707.71..13993.52 rows=1276 width=161) (actual time=164.423..361.477 rows=49 loops=1) I tried setting enable_merge_joins to off and that made the query about three times faster. It's using a hash join instead.