X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.2])
	by svr1.postgresql.org (Postfix) with ESMTP id 717CCD1D6CC
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Fri,  5 Mar 2004 21:32:04 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
	with ESMTP id 83309-04
	for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
	Fri,  5 Mar 2004 17:32:03 -0400 (AST)
Received: from davh.dk (unknown [192.38.225.107])
	by svr1.postgresql.org (Postfix) with SMTP id 38BA2D1D2C6
	for <pgsql-hackers@postgresql.org>;
	Fri,  5 Mar 2004 17:32:00 -0400 (AST)
Received: (qmail 3566 invoked from network); 5 Mar 2004 21:34:28 -0000
Received: from cine.davh.dk (HELO diku.dk) (192.168.0.110)
	by chacal.davh.dk with SMTP; 5 Mar 2004 21:34:28 -0000
Message-ID: <4048F1D3.20405@diku.dk>
Date: Fri, 05 Mar 2004 22:32:03 +0100
From: Dennis Haney <davh@diku.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040225
X-Accept-Language: da, en-us, en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: IN joining
References: <4048B8D6.70401@diku.dk> <11205.1078520699@sss.pgh.pa.us>
In-Reply-To: <11205.1078520699@sss.pgh.pa.us>
Content-Type: multipart/alternative;
	boundary="------------000603010409050600080402"
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200403/215
X-Sequence-Number: 50807

This is a multi-part message in MIME format.
--------------000603010409050600080402
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

>Dennis Haney <davh@diku.dk> writes:
>  
>
>>Consider this example:
>>SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN (SELECT c.id FROM c)
>>the possible execution trees are {{a,b}, {c}}, {{a,c},{b}} and the code 
>>seems to also permit {{b,c},{a}}.
>>    
>>
>
>No, it does not --- as you say, that would give wrong answers.  That
>case is eliminated by the tests following this comment:
>
>             * JOIN_IN technique will work if outerrel includes LHS and
>             * innerrel is exactly RHS; conversely JOIN_REVERSE_IN handles
>             * RHS/LHS.
>             *
>             * JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS;
>             * conversely JOIN_UNIQUE_INNER will work if innerrel is
>             * exactly RHS.
>
>Joining {b,c} to {a} does not meet any of those four allowed cases.
>  
>
Exactly my point... So why ever bother creating the {b,c} node which is 
legal by the above definition?


-- 
Dennis
use Inline C => q{void p(char*g){
printf("Just Another %s Hacker\n",g);}};p("Perl");


--------------000603010409050600080402
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
Tom Lane wrote:
<blockquote cite="mid11205.1078520699@sss.pgh.pa.us" type="cite">
  <pre wrap="">Dennis Haney <a class="moz-txt-link-rfc2396E"
 href="mailto:davh@diku.dk">&lt;davh@diku.dk&gt;</a> writes:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Consider this example:
SELECT * FROM a,b WHERE a.id = b.id AND (a.id) IN (SELECT c.id FROM c)
the possible execution trees are {{a,b}, {c}}, {{a,c},{b}} and the code 
seems to also permit {{b,c},{a}}.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
No, it does not --- as you say, that would give wrong answers.  That
case is eliminated by the tests following this comment:

             * JOIN_IN technique will work if outerrel includes LHS and
             * innerrel is exactly RHS; conversely JOIN_REVERSE_IN handles
             * RHS/LHS.
             *
             * JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS;
             * conversely JOIN_UNIQUE_INNER will work if innerrel is
             * exactly RHS.

Joining {b,c} to {a} does not meet any of those four allowed cases.
  </pre>
</blockquote>
Exactly my point... So why ever bother creating the {b,c} node which is
legal by the above definition?<br>
<br>
<br>
<pre class="moz-signature" cols="72">-- 
Dennis
use Inline C =&gt; q{void p(char*g){
printf("Just Another %s Hacker\n",g);}};p("Perl");
</pre>
</body>
</html>

--------------000603010409050600080402--