<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div><br>
</div>
<div>Hey Jeff-</div>
<div><br>
</div>
<div>The purpose of the UNION query with native evaluation of virtual cubes is to make sure that all of the tuples with NON EMPTY data from any of the relevant base cubes are included. &nbsp;So if a query crossjoins Products and Stores from the [Warehouse and Sales]
 cube, native eval needs to query both the sales and warehouse fact tables in order to get the full set of NON EMPTY tuples. &nbsp;It does that with queries to each fact table UNION’d together (that logic has been in place for years).</div>
<div>
<div id="MAC_OUTLOOK_SIGNATURE"></div>
</div>
</div>
</div>
<div><br>
</div>
<div>Prior to the changes for 1599/2280, SqlTupleReader would retrieve those base cubes relevant to the measures in the query, and then pare the list of cubes down to only those that join to all the dimensions in the crossjoin. &nbsp;If any measures in the query
 might change context, however, that approach could give incorrect results. &nbsp;There are some examples in the 2 jira cases.</div>
<div><br>
</div>
<div>The changes for 1599/2280 introduced grouping of native tuple queries, so we now retrieve tuples grouped by common joining base cubes. &nbsp;STR only does this if one or more measures are determined to shift context (with ValidMeasure or otherwise). &nbsp;But this
 does mean that we’re now more likely to execute UNION queries, since we’re evaluating in groups that share common cubes.</div>
<div><br>
</div>
<div>I’m definitely interested in hearing thoughts on improving performance in this scenario. &nbsp;The trick is assuring correctness, which requires knowing which tuples have non-empty data across all relevant fact tables, without executing more expensive SQL than
 necessary.&nbsp;</div>
<div><br>
</div>
<div>-matt</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:12pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>&lt;<a href="mailto:mondrian-bounces@pentaho.org">mondrian-bounces@pentaho.org</a>&gt; on behalf of &quot;<a href="mailto:jeff.s.wright@truvenhealth.com">jeff.s.wright@truvenhealth.com</a>&quot; &lt;<a href="mailto:jeff.s.wright@truvenhealth.com">jeff.s.wright@truvenhealth.com</a>&gt;<br>
<span style="font-weight:bold">Reply-To: </span>Mondrian list &lt;<a href="mailto:mondrian@pentaho.org">mondrian@pentaho.org</a>&gt;<br>
<span style="font-weight:bold">Date: </span>Friday, August 19, 2016 at 10:26 AM<br>
<span style="font-weight:bold">To: </span>Mondrian list &lt;<a href="mailto:mondrian@pentaho.org">mondrian@pentaho.org</a>&gt;<br>
<span style="font-weight:bold">Subject: </span>[Mondrian] virtual cubes, non-joining dims, performance<br>
</div>
<div><br>
</div>
<div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">I think this is primarily to Matt, but sending to mailing list in case there’s other interest or input…<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">We’ve been testing some new-ish code in an effort to get correct behavior of non-joining dimensions, and there seems to be a somewhat steep performance cost to the fix. What we’re seeing is that recent versions of SqlTupleReader generate
 an expensive UNION query across the fact tables in a virtual cube. <o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">I haven’t carefully sorted through the code our team has tested, but looking at the revision history on github, I suspect we’re testing with the checkin for issue #1, but not issue #2:<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">#1 - <a href="http://jira.pentaho.com/browse/MONDRIAN-1599">
http://jira.pentaho.com/browse/MONDRIAN-1599</a> - Some queries against Virtual cubes can give wrong results when dimensions don't fully join<o:p></o:p></p>
<p class="MsoNormal">#2 - <a href="http://jira.pentaho.com/browse/MONDRIAN-2280">
http://jira.pentaho.com/browse/MONDRIAN-2280</a> - ValidMeasure not taken into account when Analyzer uses NonEmptyCrossjoin as it returns no data<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Is the expensive UNION query something you’ve seen as well?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">--jeff<o:p></o:p></p>
</div>
</div>
</div>
</span>
</body>
</html>