Received: from localhost (unknown [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 20A1E2E0030
	for <pgsql-sql-postgresql.org@postgresql.org>;
	Wed, 27 Feb 2008 05:17:08 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 51343-07 for <pgsql-sql-postgresql.org@postgresql.org>;
	Wed, 27 Feb 2008 05:16:59 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from interscan.indicator.com (mail.indicator.be [193.121.199.3])
	by postgresql.org (Postfix) with ESMTP id 2ACA52E0041
	for <pgsql-sql@postgresql.org>; Wed, 27 Feb 2008 05:17:02 -0400 (AST)
Received: from DOMEXT-MTA by webaccess.indicator.bewith Novell_GroupWise;
	Wed, 27 Feb 2008 10:17:00 +0100
Message-Id: <47C53892.A3DD.0030.0@indicator.be>
X-Mailer: Novell GroupWise Internet Agent 7.0.1 
Date: Wed, 27 Feb 2008 10:16:51 +0100
From: "Bart Degryse" <Bart.Degryse@indicator.be>
To: "Markus Bertheau" <mbertheau.pg@googlemail.com>
Cc: <pgsql-sql@postgresql.org>
Subject: Re: Function returns error (view)
References: <6a5e3a6f0802260832k9c1375ap632f8adad0740fa2@mail.gmail.com><6a5
	e3a6f0802261020o51327bceof4845c47ae1b099d@mail.gmail.com><47C524E9.A3DD.003
	0.0@indicator.be><684362e10802270109y7d63d656jbdff332274a31456@mail.gmail.com>
In-Reply-To: <684362e10802270109y7d63d656jbdff332274a31456@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=__Part5375DC93.1__="
X-imss-version: 2.050
X-imss-result: Passed
X-imss-approveListMatch: *@indicator.be
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200802/217
X-Sequence-Number: 30308

--=__Part5375DC93.1__=
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

For rather "simple" queries like this one PostgreSQL indeed seems to be =
quite smart.
I have quite a lot of statements where it does make a difference though =
(PostgreSQL 8.2.4).
As long as I have one statement where it makes a difference I will use the =
join=20
rather than the IN(subselect) just to be sure of optimal performance.
Keeping that in mind I don't see any harm in advising others to do so too.
But you're right in stating that it's not always necessary.


>>> "Markus Bertheau" <mbertheau.pg@googlemail.com> 2008-02-27 10:09 >>>
2008/2/27, Bart Degryse <Bart.Degryse@indicator.be>:
>
> I would also suggest you replace the
> ...t.cod_user IN (subselect)
> by a join construction. I think it's more performant.

In recent versions PostgreSQL is quite smart when planning IN, so that
shouldn't be a concern.

Markus

--=20
Markus Bertheau
Blog: http://www.bluetwanger.de/blog/

--=__Part5375DC93.1__=
Content-Type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15=
">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR></HEAD>
<BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>For rather "simple" queries like this one PostgreSQL indeed seems to =
be quite smart.</DIV>
<DIV>I have quite a lot of statements where it does make a difference =
though (PostgreSQL 8.2.4).</DIV>
<DIV>As long as I have one statement where it makes a difference I will =
use the join </DIV>
<DIV>rather than the IN(subselect) just to be sure of optimal performance.<=
/DIV>
<DIV>Keeping that in mind I don't see any harm in advising others to do so =
too.</DIV>
<DIV>But you're right in stating that it's not always necessary.</DIV>
<DIV><BR><BR>&gt;&gt;&gt; "Markus Bertheau" &lt;mbertheau.pg@googlemail.com=
&gt; 2008-02-27 10:09 &gt;&gt;&gt;<BR>2008/2/27, Bart Degryse &lt;Bart.Degr=
yse@indicator.be&gt;:<BR>&gt;<BR>&gt; I would also suggest you replace =
the<BR>&gt; ...t.cod_user IN (subselect)<BR>&gt; by a join construction. I =
think it's more performant.<BR><BR>In recent versions PostgreSQL is quite =
smart when planning IN, so that<BR>shouldn't be a concern.<BR><BR>Markus<BR=
><BR>-- <BR>Markus Bertheau<BR>Blog: <A href=3D"http://www.bluetwanger.de/b=
log/">http://www.bluetwanger.de/blog/</A><BR></DIV></BODY></HTML>

--=__Part5375DC93.1__=--