Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 28BE7650129 for ; Tue, 2 Dec 2008 14:59:02 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 09669-02 for ; Tue, 2 Dec 2008 14:58:58 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp-out.neti.ee (smtp-out.neti.ee [194.126.126.44]) by mail.postgresql.org (Postfix) with ESMTP id 9A46664FDB3 for ; Tue, 2 Dec 2008 14:58:58 -0400 (AST) X-Virus-Scanned: Debian amavisd-new at estpak.ee Received: from Relayhost3.neti.ee (relayhost3.estpak.ee [88.196.174.169]) by MXR-8.estpak.ee (Postfix) with ESMTP id A74B3158FCB; Tue, 2 Dec 2008 20:58:53 +0200 (EET) X-SMTP-Auth-NETI-Businesmail: no Received: from andrusnotebook (unknown [195.50.198.194]) by Relayhost3.neti.ee (Postfix) with SMTP id A16A1D5957; Tue, 2 Dec 2008 20:58:50 +0200 (EET) Message-ID: <772C0DC9C4A04AA4939EB50F2707A791@andrusnotebook> From: "Andrus" To: "Scott Carey" , , "PFC" References: <95776070DDC841978DF8335DCF59D6BB@andrusnotebook> , <72246E216337406EAD285F5A45533672@andrusnotebook> In-Reply-To: Subject: Re: analyzing intermediate query Date: Tue, 2 Dec 2008 20:58:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=STOX_REPLY_TYPE=0.001 X-Spam-Level: X-Archive-Number: 200812/18 X-Sequence-Number: 32054 Scott, >Often times, switching an inner subselect that requires a distinct to a >group by on that column yields better results. In this case, the IN should >be equivalent, so it probably will not help. This would look like: SELECT dok.* FROM dok JOIN (SELECT dokumnr FROM temptbl GROUP BY dokumnr ) x USING(dokumnr); Thank you. This may be great idea. I changed my query to use GROUP BY instead of DISTINCT >Whether that hepls depends on how big dokumnr is and where the query >bottleneck is. I'm wondering how this can solve the issue when there is single or few dokumnr columns. Planner still thinks that temptbl projection contains 1000 rows and uses seq scan instead of using bitmap index on dok table. I tried SELECT dok.* FROM dok JOIN (SELECT dokumnr FROM temptbl GROUP BY dokumnr ANALYZE ) x USING(dokumnr); but got error. > Note there are subtle differences between DISTINCT and GROUP BY with > respect to nulls. dokumnr is int type and is not null always. Andrus.