<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Null-Aware Anti-Join</title>
	<atom:link href="http://structureddata.org/2008/05/22/null-aware-anti-join/feed/" rel="self" type="application/rss+xml" />
	<link>http://structureddata.org/2008/05/22/null-aware-anti-join/</link>
	<description>Oracle Database Performance And Scalability Blog</description>
	<lastBuildDate>Mon, 01 Mar 2010 22:11:26 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Greg Rahn</title>
		<link>http://structureddata.org/2008/05/22/null-aware-anti-join/comment-page-1/#comment-211</link>
		<dc:creator>Greg Rahn</dc:creator>
		<pubDate>Thu, 29 May 2008 17:48:27 +0000</pubDate>
		<guid isPermaLink="false">http://structureddata.org/?p=64#comment-211</guid>
		<description>The current anti-join is not &quot;broken&quot; it just does not work with every possible case because of transformation restrictions.  This is why the null-aware anti-join was created.  Think of it as a new type of join; a superset of what previously existed.

If you are asking if there will be a null-aware version of the previous transformations that were not null-aware, the answer would be yes.</description>
		<content:encoded><![CDATA[<p>The current anti-join is not &#8220;broken&#8221; it just does not work with every possible case because of transformation restrictions.  This is why the null-aware anti-join was created.  Think of it as a new type of join; a superset of what previously existed.</p>
<p>If you are asking if there will be a null-aware version of the previous transformations that were not null-aware, the answer would be yes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Todor Botev</title>
		<link>http://structureddata.org/2008/05/22/null-aware-anti-join/comment-page-1/#comment-214</link>
		<dc:creator>Todor Botev</dc:creator>
		<pubDate>Thu, 29 May 2008 08:17:20 +0000</pubDate>
		<guid isPermaLink="false">http://structureddata.org/?p=64#comment-214</guid>
		<description>My question comes down to: why just not &quot;fix&quot; the regular anti join so that the nulls are handled correctly?

If the null-aware path is followed consistently, we should end up with virtually all transformations doubled with there null-aware twins, schoudn&#039;t we?</description>
		<content:encoded><![CDATA[<p>My question comes down to: why just not &#8220;fix&#8221; the regular anti join so that the nulls are handled correctly?</p>
<p>If the null-aware path is followed consistently, we should end up with virtually all transformations doubled with there null-aware twins, schoudn&#8217;t we?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Greg Rahn</title>
		<link>http://structureddata.org/2008/05/22/null-aware-anti-join/comment-page-1/#comment-210</link>
		<dc:creator>Greg Rahn</dc:creator>
		<pubDate>Wed, 28 May 2008 21:01:52 +0000</pubDate>
		<guid isPermaLink="false">http://structureddata.org/?p=64#comment-210</guid>
		<description>I believe it comes down to how NULL is treated and the restrictions around how the query can be transformed if its presence is allowed.   If you read the patent application, starting at [0035] &lt;em&gt;The Bane of Nulls&lt;/em&gt;, you will see some examples are worked.  Specifically:
&lt;blockquote&gt;[0041] Suppose T1.x has the following set of values: {NULL,5,8,11}.  Query Q2, the transformed query generated by regular anti-join unnesting, incorrectly returns {NULL,5}.
[0042] Suppose the subquery in Q1 returns the following set of values {7,8,11} and T1.x has the same set of values {NULL,5,8,11}.  The correct result of Q1 is {5}.  Regular anti-join unnesting again incorrectly returns {NULL,5}.
&lt;/blockquote&gt;

Both of these cases demonstrate how the presence of NULL with a regular anti-join produce incorrect results.

I&#039;m not sure if I understand your second question.  If an anti-join is made null-aware, is it not a null-aware anti-join?</description>
		<content:encoded><![CDATA[<p>I believe it comes down to how NULL is treated and the restrictions around how the query can be transformed if its presence is allowed.   If you read the patent application, starting at [0035] <em>The Bane of Nulls</em>, you will see some examples are worked.  Specifically:</p>
<blockquote><p>[0041] Suppose T1.x has the following set of values: {NULL,5,8,11}.  Query Q2, the transformed query generated by regular anti-join unnesting, incorrectly returns {NULL,5}.<br />
[0042] Suppose the subquery in Q1 returns the following set of values {7,8,11} and T1.x has the same set of values {NULL,5,8,11}.  The correct result of Q1 is {5}.  Regular anti-join unnesting again incorrectly returns {NULL,5}.
</p></blockquote>
<p>Both of these cases demonstrate how the presence of NULL with a regular anti-join produce incorrect results.</p>
<p>I&#8217;m not sure if I understand your second question.  If an anti-join is made null-aware, is it not a null-aware anti-join?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Todor Botev</title>
		<link>http://structureddata.org/2008/05/22/null-aware-anti-join/comment-page-1/#comment-209</link>
		<dc:creator>Todor Botev</dc:creator>
		<pubDate>Wed, 28 May 2008 06:56:16 +0000</pubDate>
		<guid isPermaLink="false">http://structureddata.org/?p=64#comment-209</guid>
		<description>Thanks for the good post!

What do you think - why is the Null-Aware Anti-Join so special that it deserves a specially named query transformation? The &quot;regular&quot; Anti-Join can just be also null-aware, can&#039;t it? Or is there any standard (patent) preventing that?</description>
		<content:encoded><![CDATA[<p>Thanks for the good post!</p>
<p>What do you think &#8211; why is the Null-Aware Anti-Join so special that it deserves a specially named query transformation? The &#8220;regular&#8221; Anti-Join can just be also null-aware, can&#8217;t it? Or is there any standard (patent) preventing that?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken Roytman</title>
		<link>http://structureddata.org/2008/05/22/null-aware-anti-join/comment-page-1/#comment-215</link>
		<dc:creator>Ken Roytman</dc:creator>
		<pubDate>Fri, 23 May 2008 15:04:10 +0000</pubDate>
		<guid isPermaLink="false">http://structureddata.org/?p=64#comment-215</guid>
		<description>Very cool article.  I like the link straight to the patent application.

Your blog is a joy to read.  Thank you for your contributions!</description>
		<content:encoded><![CDATA[<p>Very cool article.  I like the link straight to the patent application.</p>
<p>Your blog is a joy to read.  Thank you for your contributions!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Tkatch</title>
		<link>http://structureddata.org/2008/05/22/null-aware-anti-join/comment-page-1/#comment-212</link>
		<dc:creator>Brian Tkatch</dc:creator>
		<pubDate>Thu, 22 May 2008 11:45:03 +0000</pubDate>
		<guid isPermaLink="false">http://structureddata.org/?p=64#comment-212</guid>
		<description>Nice write-up. Thanx.</description>
		<content:encoded><![CDATA[<p>Nice write-up. Thanx.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob van Wijk</title>
		<link>http://structureddata.org/2008/05/22/null-aware-anti-join/comment-page-1/#comment-213</link>
		<dc:creator>Rob van Wijk</dc:creator>
		<pubDate>Thu, 22 May 2008 08:30:48 +0000</pubDate>
		<guid isPermaLink="false">http://structureddata.org/?p=64#comment-213</guid>
		<description>That&#039;s great news. Rewriting those &quot;not in&quot; queries on nullable columns is apparently not needed anymore in 11g.

Thanks for the excellent article.

Regards,
Rob.</description>
		<content:encoded><![CDATA[<p>That&#8217;s great news. Rewriting those &#8220;not in&#8221; queries on nullable columns is apparently not needed anymore in 11g.</p>
<p>Thanks for the excellent article.</p>
<p>Regards,<br />
Rob.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
