[Mondrian] are readTuple queries really necessary ?

Luc Boudreau lucboudreau at gmail.com
Thu Jan 30 09:41:36 EST 2014


Hello Arvind,

We've been discussing merging the segment and tuple queries for some time
now, but their separation is at the core of the algorithm which resolves a
query into its result. It isn't a trivial matter to merge the two together,
and so far it hasn't happened.

As for the tuple queries using the fact table, this usually happens when an
MDX statement asks for the non empty tuples. In that situation, we join
through the fact table and voila. If the crossjoin is simple enough, the
fact table should be omitted from the query.

Luc


On Thu, Jan 30, 2014 at 2:42 AM, Arvindkumar J <j.arvindkumar at gmail.com>wrote:

> Hi All,
>
> I have a query regarding SQL query generation.
>
> For each MDX query, mondrian fires set of readTuple queries and
> segment.load queries.
> I understand that readTuple queries are used to populate the axes and
> segment load queries to populate the cell values. So usually there are more
> readTuple queries compared to segment.load queries.
>
> Why can't we avoid the readTuple queries in case where the predicates are
> fixed ?
> (i know we can't avoid in-case the predicates are like [Product].children
> ).
> Instead, we can populate the axes from the input predicates and filtering
> of tuples with 0 values can be doneter the segment load queries.
>
> The reason i'm asking this is the readTuple queries are taking major part
> of the query time. And i notice these queries are on fact tables. Are these
> queries supposed to be on fact tables or only dimension tables ?
>
> Please correct me if my understanding is not correct.
>
> Thanks
> Arvind
>
>
> _______________________________________________
> 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/20140130/1704df11/attachment.html 


More information about the Mondrian mailing list