Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 85F942E0047 for ; Tue, 6 May 2008 06:47:40 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 96570-04 for ; Tue, 6 May 2008 06:47:32 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from 27.mail-out.ovh.net (27.mail-out.ovh.net [91.121.30.210]) by developer.postgresql.org (Postfix) with SMTP id 978932E0041 for ; Tue, 6 May 2008 06:47:35 -0300 (ADT) Received: (qmail 29107 invoked by uid 503); 6 May 2008 11:42:04 -0000 Received: from gw2.ovh.net (HELO mail170.ha.ovh.net) (213.251.189.202) by 27.mail-out.ovh.net with SMTP; 6 May 2008 11:42:04 -0000 Received: from b0.ovh.net (HELO queue-out) (213.186.33.50) by b0.ovh.net with SMTP; 6 May 2008 09:47:27 -0000 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO apollo13.peufeu.com) (88.161.102.87) by ns0.ovh.net with SMTP; 6 May 2008 09:47:27 -0000 To: "Frank van Vugt" , pgsql-performance@postgresql.org Subject: Re: plan difference between set-returning function with ROWS within IN() and a plain join From: PFC Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200805061021.43448.ftm.van.vugt@foxi.nl> Content-Transfer-Encoding: 7bit Date: Tue, 06 May 2008 11:53:17 +0200 Message-ID: In-Reply-To: <200805061021.43448.ftm.van.vugt@foxi.nl> User-Agent: Opera Mail/9.24 (Linux) X-Ovh-Tracer-Id: 2967590679772726829 X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|H 0.5/N X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.662 tagged_above=0 required=5 tests=AWL=0.662 X-Spam-Level: X-Archive-Number: 200805/73 X-Sequence-Number: 30041 On Tue, 06 May 2008 10:21:43 +0200, Frank van Vugt wrote: > L.S. > > I'm noticing a difference in planning between a join and an in() clause, > before trying to create an independent test-case, I'd like to know if > there's > an obvious reason why this would be happening: Is the function STABLE ?