[Mondrian] query model 2.0 / named set performance?

Paul Stoellberger p.stoellberger at gmail.com
Fri Mar 23 17:44:04 EDT 2012


One other note.. instead of using that filter thing it seems like using Exists() works too.
I'm kind of surprised of it... how does this function work exactly (msdn couldn't really help me either), I thought it was something else
I actually use Exists() in the current olap4j query model, as Filter(<member> IN <set>) is mondrian specific und doesn't work on SSAS.


Anyhow, instead of that Filter thing I could just do:
Exists( {[Product].[Product Department].Members} , {Product.Drink} ) 

That one will only give me members of Product Department that are children of Product.Drink.

How? Why?
Since the function signature is Exists(<set>, <set>) I can even define other members in that set.

Maybe someone could help me out with a clarification on that function?
And would you see any negative consequences of using it in my context?


Thanks for your feedback Nick and Pedro!

-Paul

On Mar 23, 2012, at 10:28 PM, Pedro Alves wrote:

> I use that technique a lot, never had problems or noticed performance impact 
> 
> 
> 
> -pedro
> 
> Paul Stoellberger <p.stoellberger at gmail.com> wrote:
> Hi,
> 
> I've been tinkering with various options for the mdx we could use for an improved query model, and I was wondering if named sets had any (negative) impact on performance.
> I just want to use them to simplify the mdx and improve its readability.
> 
> For each level I would create a separate set.
> Basically the whole concept is very level based.... that way users can perform stuff like TopCount, Filter, ... on specific levels, or a level could be a period instead of specific members.
> 
> A query could e.g. look like this:
> 
> with 
> set [ProductFamily] as '{[Product].[Food]}'
> set [ProductDepartment] as 'Filter({[Product].[Food].[Dairy], [Product].[Food].[Meat]}, Ancestor(Product.CurrentMember,[Product Family]) in [ProductFamily])'
> set [ProductCategory] as 'Filter({[Product].[Product Category].Members}, Ancestor(Product.CurrentMember,[Product
> Department]) in [ProductDepartment])'
> set [ProductDimension] as 'Hierarchize({[ProductFamily], [ProductDepartment],[ProductCategory]})'
> SELECT
> NON EMPTY {[Customers].[All Customers]} ON COLUMNS,
> NON EMPTY [ProductDimension] ON ROWS
> FROM [Sales]
> 
> 
> 
> on an axis i would then just do something like:
> SELECT [Dimension1] * [Dimension2] ON COLUMNS, .....
> 
> 
> I was trying to figure out a way that would work with DrillDownLevel and/or DrillDownMember .... but unfortunately they can only drill down 1 level and i wanted this to be a more general solution.
> Otherwise I would have definitely preferred that.
> 
> 
> Any Input on this from anyone who has an opinion would be highly appreciated.
> 
> Thanks,
> Paul
> 
> 
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20120323/f991281b/attachment-0001.html 


More information about the Mondrian mailing list