<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.5730.11" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>As Michael already mentioned, Option #2 could have troubles
with database transactions. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>When running against a dynamic </FONT></SPAN><SPAN
class=187352607-13022007><FONT face=Arial color=#0000ff size=2>database, option
#2 will make it even more difficult to keep the cache
integrity.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>While I think it would be better that a central cache
manager would have multiple threads to load the results (both aggregates as
hierarchies) and</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>would run separately from the mdx query executing threads
(just making requests to the cache). There could
still</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>be problems when multiple threads would read the same cube
data using different transactions. In some cases</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>you might allow each cube (when using virtual cubes) to
have a single thread, but still, in most cases, this would
lead</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>to problems.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>For example : When calculating aggregate tables at night,
it is possible that one sql query depends on a newer</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>version (an aggregate table already updated), and another
query depending on an aggregate table yet to be updated.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>While database transactions are not there yet, it would
make future work in that direction more difficult, it might be
impossible.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>I see a lot of movement in different directions for the
moment, about scalability, multi user access, integrity, dynamic
databases,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>huge results, small real time results... But I notice
that some decisions don't cover the whole idea or are not compatible with
each other.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>I think it would be useful if there was an analysis made of
the whole idea, with a roadmap supporting this vision, or at least each
direction </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>that is not compatible </FONT></SPAN><SPAN
class=187352607-13022007><FONT face=Arial color=#0000ff size=2>with other usages
of mondrian, should be made configurable. So it would be possible - at
cube level - or at </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=187352607-13022007><FONT face=Arial
color=#0000ff size=2>mondrian.properties level to </FONT></SPAN><SPAN
class=187352607-13022007><FONT face=Arial color=#0000ff size=2>configure how
mondrian will behave.</FONT></SPAN></DIV>
<DIV> </DIV>
<DIV><SPAN class=187352607-13022007></SPAN><FONT face=Arial><FONT
color=#0000ff><FONT size=2>B<SPAN
class=187352607-13022007>art</SPAN></FONT></FONT></FONT></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> mondrian-bounces@pentaho.org
[mailto:mondrian-bounces@pentaho.org] <B>On Behalf Of </B>Julian
Hyde<BR><B>Sent:</B> dinsdag 13 februari 2007 2:38<BR><B>To:</B> 'Mondrian
developer mailing list'<BR><B>Subject:</B> RE: [Mondrian] Multi-threading SQL
execution<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2><STRONG>Option #1 (ROLLUP/CUBE BY) </STRONG>is viable and
useful. If there are differences between DBMS vendors in how they implement this
support, let's stick to the letter of the SQL:2003 standard.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2>To implement option #1, someone will have to get their
hands dirty understanding how cell requests are turned into SQL queries. The
hardest part is to look at a collection of cell requests and figure out whether
they can be satisfied using the same query.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2>Is there a chance that a ROLLUP query will compute
exponentially more results than individual GROUP BY queries? If so, we will need
to do a cost:benefit analysis before issuing a ROLLUP query.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2><STRONG>Option #2 (parallel query execution) </STRONG>is
also viable, and is useful if option #1 is implemented, because certain
queries, especially those on virtual cubes, may generate queries which are not a
rollup of each other.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2>Implementing option #2 it requires a modest amount of
coding, mainly introducing a multi-threaded request queue, and a significant
amount of testing for threading issues.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2>A <STRONG>third option is to support rollup within
cache</STRONG>. If mondrian notices that there is a request for
([Time].[1997].[Q1], ... [Q4], [Product].[Beer]) and also a request for
([Time].[1997], [Product].[Beer]) then it should execute request #1 then answer
request #2 by rolling up the results of request #1.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2>ALL of these options will benefit mondrian and each offers
something that the other two do not, so it's difficult to choose between them.
My instinct is that </FONT></SPAN><SPAN class=503022400-13022007><FONT
face=Verdana color=#000080 size=2>option #2 is slightly less work than option
#1, but has less benefit. Take your pick!</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080 size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=503022400-13022007><FONT face=Verdana
color=#000080
size=2>Julian</FONT></SPAN></DIV><BR>______________________________________________________________________<BR>This
email has been scanned by the Email Security
System.<BR>______________________________________________________________________<BR></BODY></HTML>