[Mondrian] Re: Performance degradation

Matt Campbell mkambol at gmail.com
Tue Mar 3 18:47:39 EST 2009


Hi peter- this query was run *without* native nonempty turned on.

On 3/3/09, Peter Tran <ptran at prospricing.com> wrote:
> Matt,
>
> Are you doing native evaluation?  We found a case where Mondrian was doing
> non-native evaluation based on how the MDX was structured which had a huge
> impact on performance.
>
> Check to see whether the crossjoin is being pushed down natively to the
> database.
>
> -Peter
>
> ________________________________
> From: mondrian-bounces at pentaho.org [mailto:mondrian-bounces at pentaho.org] On
> Behalf Of Matt Campbell
> Sent: Tuesday, March 03, 2009 4:25 PM
> To: Mondrian developer mailing list
> Subject: [Mondrian] Re: Performance degradation
>
> I was able to reproduce this issue with a very simple Foodmart query.  The
> following runs in under 2 seconds with changelist 10915.  It now takes
> around 55 seconds with 12403.   From the little investigation I've done it
> looks like most time is spent in executeStripe().
>
> It's interesting, if I eliminate either part of the set the time drops back
> down to ~2 seconds--i.e. eliminate either the GENERATE() or the
> {Product.DEFAULTMEMBER, [Yearly Income].DEFAULTMEMBER}.  If they are both
> present, though, it takes 55 seconds.
>
> SELECT
>             {GENERATE({[Product].[Product Name].MEMBERS},
>              CROSSJOIN( {([Product].CURRENTMEMBER)},
>            {[Yearly Income].[Yearly Income].MEMBERS}), ALL),
>             {([Product].DEFAULTMEMBER,[Yearly Income].DEFAULTMEMBER)}
> }
>  ON AXIS(0)
> FROM
>             [Sales] ;
>
>
> On Tue, Mar 3, 2009 at 11:03 AM, Matt Campbell
> <mkambol at gmail.com<mailto:mkambol at gmail.com>> wrote:
>
> During a run of a performance test we noticed a fairly significant increase
> in query time for queries involving very large numbers of cells.  We
> actually hadn't run this particular test in nearly a year, so the comparison
> is between changelist 10915 and 12403.
>
> The query is ridiculously large--nearly 200K tuples, intersected with 12
> measures.  With 10915 this query ran in a little over an hour.  With 12403
> it runs for over 5 hours.
>
> I haven't investigated much yet.  I'm going to create simple Foodmart query
> to try to reproduce, and then I'll try to narrow down where the bottleneck
> is.  I wanted to post, though, in case anyone has thoughts about this.
>
>
>
>




More information about the Mondrian mailing list