Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 03E33634BC3 for ; Wed, 10 Mar 2010 10:05:38 -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 86619-02 for ; Wed, 10 Mar 2010 14:05:12 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by mail.postgresql.org (Postfix) with ESMTP id 79891633FF7 for ; Wed, 10 Mar 2010 10:05:20 -0400 (AST) Received: by ewy27 with SMTP id 27so3928053ewy.34 for ; Wed, 10 Mar 2010 06:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=EvwN3rdt+k76SX/PHXWUjV7k+ekJhJgk8vG6fXK/I8w=; b=oTii6xVythrw+AJyFKnOQZ4GhROoz6TO2S+qhyeoCN6Byx54BkVkxrr/trjrfMWMCJ TM2O5gT9rOgjeKdLcEYHKK+j7AF5UPXqLtUl+8qSUK4ybSn79/KHLuOjR1B/7/WSAQaR ONfYvPc9tfpB3wJ/RMbbu7FajzgsQAiDUaox4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bMMSDRAHpovpGT+d4DKbMH32CeorNSMC4eJq5CeFfnhtrEgzVRKByXNPCx3NfQoV36 EiySxVH3SwEgi21aQf4Za5HoBDSj4zwkAoKQDB74C5y07RWd0CG0pvllzFj1mwe4zY2r rhGvN/PlJFybFZ8hZiGIKaJpp/QpnPLGYMT5w= Received: by 10.213.100.210 with SMTP id z18mr929243ebn.65.1268229918604; Wed, 10 Mar 2010 06:05:18 -0800 (PST) Received: from [0.0.0.0] (5357DA75.cable.casema.nl [83.87.218.117]) by mx.google.com with ESMTPS id 14sm3868253ewy.10.2010.03.10.06.05.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Mar 2010 06:05:17 -0800 (PST) Message-ID: <4B97A720.4080304@gmail.com> Date: Wed, 10 Mar 2010 15:05:20 +0100 From: Yeb Havinga User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kenneth Marshall CC: Benoit Delbosc , pgsql-performance@postgresql.org Subject: Re: Bad query plan inside EXISTS clause References: <4B979DFC.7080509@nuxeo.com> <20100310134342.GA29320@it.is.rice.edu> <4B97A3C8.6000509@gmail.com> In-Reply-To: <4B97A3C8.6000509@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.343 tagged_above=-10 required=5 tests=AWL=0.256, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/112 X-Sequence-Number: 37937 Yeb Havinga wrote: > Kenneth Marshall wrote: >> EXISTS matches NULLs too and since they are not indexed a >> sequential scan is needed to check for them. Try using >> IN instead. >> > This is nonsense in more than one way. Hit ctrl-return a bit too slow - exists does not match null but a set of records, that is either empty or not empty. Also it is possible to index table columns with nulls, and then the indexes can still be used. Besides filtering record sets with expressions, indexes are also used for ordering. There the effect of indexes with nulls can be seen: where to put them: in front or after the non nulls? So indexes can be perfectly used in conjunction with nulls. I found the original mail rather intriguing and played with an example myself a bit, but could not repeat the behavior (9.0 devel version), in my case the exists used an index. Maybe it has something to do with the fact that the planner estimates to return 50000 rows, even when the actual numbers list only 1 hit. In the exists case, it can stop at the first hit. In the select all rows case, it must return all rows. Maybe a better plan emerges with better statistics? regards, Yeb Havinga