<?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: Minimising Data Movement in PDW Using Query Optimisation Techniques	</title>
	<atom:link href="https://lobsterpot.com.au/blog/2014/12/05/minimising-data-movement-in-pdw-using-query-optimisation-techniques/feed/" rel="self" type="application/rss+xml" />
	<link>https://lobsterpot.com.au/blog/2014/12/05/minimising-data-movement-in-pdw-using-query-optimisation-techniques/</link>
	<description></description>
	<lastBuildDate>Mon, 23 Feb 2015 15:02:14 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>
	<item>
		<title>
		By: Rob Farley		</title>
		<link>https://lobsterpot.com.au/blog/2014/12/05/minimising-data-movement-in-pdw-using-query-optimisation-techniques/#comment-2505</link>

		<dc:creator><![CDATA[Rob Farley]]></dc:creator>
		<pubDate>Mon, 23 Feb 2015 15:02:14 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.lobsterpot.com.au/?p=3392#comment-2505</guid>

					<description><![CDATA[Hi Davos,
It&#039;s the Query Optimizer that rewrites the queries.
In the example where you can&#039;t see the &#039;Unknown&#039; tables, it&#039;s because there has been data movement, and that data is stored in the tempdb tables.
I&#039;m saying the view is a good thing. It forces the extra predicates to be used, which contradict with each other on the joins that would require data movement. This means that the data movement doesn&#039;t happen, and the query runs faster. :)
And yes - I&#039;m creating similar views for Sales, SaleItems, Delivery_SaleItems and Deliveries, and then using the views &#034;naively&#034;, and you put it.
And the sky is blue because other frequencies of light don&#039;t scatter enough for us to be able to see them when the sun&#039;s light hit various tiny particles in the atmosphere.
Rob]]></description>
			<content:encoded><![CDATA[<p>Hi Davos,<br />
It&#8217;s the Query Optimizer that rewrites the queries.<br />
In the example where you can&#8217;t see the &#8216;Unknown&#8217; tables, it&#8217;s because there has been data movement, and that data is stored in the tempdb tables.<br />
I&#8217;m saying the view is a good thing. It forces the extra predicates to be used, which contradict with each other on the joins that would require data movement. This means that the data movement doesn&#8217;t happen, and the query runs faster. 🙂<br />
And yes &#8211; I&#8217;m creating similar views for Sales, SaleItems, Delivery_SaleItems and Deliveries, and then using the views &quot;naively&quot;, and you put it.<br />
And the sky is blue because other frequencies of light don&#8217;t scatter enough for us to be able to see them when the sun&#8217;s light hit various tiny particles in the atmosphere.<br />
Rob</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Davos		</title>
		<link>https://lobsterpot.com.au/blog/2014/12/05/minimising-data-movement-in-pdw-using-query-optimisation-techniques/#comment-2504</link>

		<dc:creator><![CDATA[Davos]]></dc:creator>
		<pubDate>Tue, 17 Feb 2015 14:30:33 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.lobsterpot.com.au/?p=3392#comment-2504</guid>

					<description><![CDATA[This is very interesting and I think has implications for Enterprise Edition where tables have been partitioned. I am working with a system currently where the only way to get SQL Server to do partition elimination is to generate queries very similar to the UNION ALL of small subqueries with predicates that align perfectly to the partition function. 
I was reading the bit where you introduced contradictions, and then didn&#039;t get how you actually used them in the query. I don&#039;t think they are contradictions, they are more like obvious truths, or simulating constraints as you mentioned. &#034;from KnownCustomer where customerID &#062; 0&#034; is not a contradiction, it is always true, right?
You&#039;ve said:
&#034;Before the predicates are used, the query on the views is rewritten as follows (with SELECT clauses replaced by ellipses).&#034;
Do you mean that a person re-writes this or the query optimiser?
Also in the example following I don&#039;t see any reference to the unknown_customer table. Am I missing something?
Then you said:
&#034;Whereas with the inclusion of the additional predicates, the query simplifies to:&#034;
Are you saying that having this view is good or bad?:
CREATE VIEW dbo.Sales AS
SELECT *
FROM dbo.Sales_KnownCustomer
WHERE CustomerID &#062; 0
UNION ALL
SELECT *
FROM dbo.Sales_UnknownCustomer
WHERE CustomerID = 0;
If you join to this view with all of those associated tables is the query optimiser re-writing all of those queries to join the KnownCustomer related tables and then unioning all to the unknownCustomer joins? 
Are you creating similar views for all of these associated tables and then just joining those views together naively and the query optimiser is doing the awesome no-move thing? 
Why is the sky blue?]]></description>
			<content:encoded><![CDATA[<p>This is very interesting and I think has implications for Enterprise Edition where tables have been partitioned. I am working with a system currently where the only way to get SQL Server to do partition elimination is to generate queries very similar to the UNION ALL of small subqueries with predicates that align perfectly to the partition function.<br />
I was reading the bit where you introduced contradictions, and then didn&#8217;t get how you actually used them in the query. I don&#8217;t think they are contradictions, they are more like obvious truths, or simulating constraints as you mentioned. &quot;from KnownCustomer where customerID &gt; 0&quot; is not a contradiction, it is always true, right?<br />
You&#8217;ve said:<br />
&quot;Before the predicates are used, the query on the views is rewritten as follows (with SELECT clauses replaced by ellipses).&quot;<br />
Do you mean that a person re-writes this or the query optimiser?<br />
Also in the example following I don&#8217;t see any reference to the unknown_customer table. Am I missing something?<br />
Then you said:<br />
&quot;Whereas with the inclusion of the additional predicates, the query simplifies to:&quot;<br />
Are you saying that having this view is good or bad?:<br />
CREATE VIEW dbo.Sales AS<br />
SELECT *<br />
FROM dbo.Sales_KnownCustomer<br />
WHERE CustomerID &gt; 0<br />
UNION ALL<br />
SELECT *<br />
FROM dbo.Sales_UnknownCustomer<br />
WHERE CustomerID = 0;<br />
If you join to this view with all of those associated tables is the query optimiser re-writing all of those queries to join the KnownCustomer related tables and then unioning all to the unknownCustomer joins?<br />
Are you creating similar views for all of these associated tables and then just joining those views together naively and the query optimiser is doing the awesome no-move thing?<br />
Why is the sky blue?</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
