Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Organization: Aglio Database Solutions
To: Ryan Bradetich <rbradetich@uswest.net>
Subject: Re: slow query
Date: Sun, 23 Feb 2003 13:47:58 -0800
User-Agent: KMail/1.4.3
Cc: Oleg Lebedev <oleg.lebedev@waterford.org>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
References: <993DBE5B4D02194382EC8DF8554A5273033583@postoffice.waterford.org>
	<200302231252.30681.josh@agliodbs.com>
	<1046034334.13010.3.camel@beavis.ybsoft.com>
In-Reply-To: <1046034334.13010.3.camel@beavis.ybsoft.com>
MIME-Version: 1.0
Message-Id: <200302231347.58960.josh@agliodbs.com>
Content-Transfer-Encoding: quoted-printable

Ryan,

> > The above should use an EXISTS clause, not IN, unless you are absolutely
> > sure that the subquery will never return more than 12 rows.
>
> I am assuming you said this because EXISTS is faster for > 12 rows?
> Interesting :)

That's my rule of thumb, *NOT* any kind of relational-calculus-based truth.

Basically, one should only use IN for a subquery when one is *absolutely* s=
ure=20
that the subquery will only return a handful of records, *and* the subquery=
=20
doesn't have to do an complex work like aggregating or custom function=20
evaluation.=20=20

You're safer using EXISTS for all subqueries, really.

--=20
Josh Berkus
Aglio Database Solutions
San Francisco