Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id C9C12635F7A for ; Wed, 10 Mar 2010 12:35:19 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 14528-07 for ; Wed, 10 Mar 2010 16:35:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mail.postgresql.org (Postfix) with ESMTP id 0353B635A2B for ; Wed, 10 Mar 2010 12:35:08 -0400 (AST) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1NpOsB-00044z-Db for pgsql-performance@postgresql.org; Wed, 10 Mar 2010 17:35:03 +0100 Received: from srv.protecting.net ([212.126.218.242]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Mar 2010 17:35:03 +0100 Received: from hari.fuchs by srv.protecting.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Mar 2010 17:35:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: pgsql-performance@postgresql.org From: Harald Fuchs Subject: Re: Strange workaround for slow query Date: Wed, 10 Mar 2010 17:29:25 +0100 Lines: 15 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: srv.protecting.net X-Archive: encrypt User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Cancel-Lock: sha1:3HKDrxbh4GAIyjs7TSiC1NkJge8= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.597 tagged_above=-10 required=5 tests=AWL=0.002, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/115 X-Sequence-Number: 37940 In article , sverhagen@wps-nl.com writes: > SELECT * FROM events_events LEFT OUTER JOIN events_event_types ON eventType_id= > events_event_types.id WHERE severity=70 AND (eventType_id IN (71)) ORDER BY > datetime DESC LIMIT 50; > Now I have at least two possibilities: > - Implementing the dummy value as shown above in my source code to improve > query performance (dirty but effective) > - Further investigating what is going on, which at this point is something I > need help with First I'd change the query. You build an OUTER JOIN and immediately convert it to an INNER JOIN by referencing the "severity" column. Then show us what EXPLAIN ANALYZE says to the problem.