Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 6DE49650DBC for ; Mon, 30 Jun 2008 01:34:18 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 28428-10 for ; Mon, 30 Jun 2008 01:33:58 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by postgresql.org (Postfix) with ESMTP id 5C99A650CF5 for ; Mon, 30 Jun 2008 01:33:58 -0300 (ADT) Received: by rv-out-0506.google.com with SMTP id b25so1367504rvf.43 for ; Sun, 29 Jun 2008 21:33:57 -0700 (PDT) Received: by 10.141.136.19 with SMTP id o19mr2336660rvn.281.1214800437309; Sun, 29 Jun 2008 21:33:57 -0700 (PDT) Received: by 10.140.174.7 with HTTP; Sun, 29 Jun 2008 21:33:57 -0700 (PDT) Message-ID: <3073cc9b0806292133l397f0d8etef06b5bb3aba13ae@mail.gmail.com> Date: Sun, 29 Jun 2008 23:33:57 -0500 From: "Jaime Casanova" To: "Tom Lane" Subject: Re: Subquery WHERE IN or WHERE EXISTS faster? Cc: Ulrich , pgsql-performance@postgresql.org In-Reply-To: <29009.1214668423@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <48665741.2060900@gmx.net> <29009.1214668423@sss.pgh.pa.us> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.585 tagged_above=0 required=5 tests=AWL=0.585 X-Spam-Level: X-Archive-Number: 200806/219 X-Sequence-Number: 30569 On Sat, Jun 28, 2008 at 10:53 AM, Tom Lane wrote: > Ulrich writes: >> People say that [EXISTS is faster] > > People who say that are not reliable authorities, at least as far as > Postgres is concerned. But it is always a bad idea to extrapolate > results on toy tables to large tables --- quite aside from measurement > noise and caching issues, the planner might pick a different plan when > faced with large tables. Load up a realistic amount of data and then > see what you get. > i've made some queries run faster using EXISTS instead of large IN clauses... actually, it was NOT EXISTS replacing a NOT IN while i'm not telling EXISTS is better i actually know in some cases is bet= ter --=20 Atentamente, Jaime Casanova Soporte y capacitaci=F3n de PostgreSQL Guayaquil - Ecuador Cel. (593) 87171157