[Mondrian] Infobright Distinct Count
Tom Barber
Tom.Barber at ecommera.co.uk
Thu Feb 10 15:07:30 EST 2011
Hey Julian,
The other thing I found on the WWW was
"In regard to query performance, users should see gains ranging from 20 - 400% depending on the type of query. Most notably, performance gains will be greatest for queries using AND, OR operators and IN clause; Order by, Group by; Union and Union all; Joins (LEFT OUTER Joins, Large – Large Joins, Small – Large Joins) and VarChar performance using Lookup."
So I shall update my dev server to 3.5.2 and check to see if IN works properly.
Tom
________________________________________
From: mondrian-bounces at pentaho.org [mondrian-bounces at pentaho.org] On Behalf Of Tom Barber [Tom.Barber at ecommera.co.uk]
Sent: 10 February 2011 16:19
To: jhyde at pentaho.com; 'Mondrian developer mailing list'
Subject: RE: [Mondrian] Infobright Distinct Count
Thanks for that Julian,
I've been tinkering today and when I set
allowsCompoundCountDistinct()
and
supportsGroupByExpressions()
to true the test suite still runs okay it seems (same 3 failures).
Don't bother with
supportsMultiValueInExpr()
IN's are still abysmal.
What I'll probably do is compile a test jar from this source with my tweaks and slap it on my dev box and run my dashboards through it, see if I get the performance boost my bosses are craving.
Cheers
Tom
________________________________________
From: Julian Hyde [jhyde at pentaho.com]
Sent: 10 February 2011 16:05
To: Tom Barber; 'Mondrian developer mailing list'
Subject: RE: [Mondrian] Infobright Distinct Count
> Tom wrote:
>
> I ran the test suite in its current suite through InfoBright
> and attached the log.
>
> Excuse my mornic understanding, but if I run the test suite
> as is, doesn't it run with the current IB dialect and prove
> nothing? :)
You'd be testing against a version of Infobright that we haven't tested
against before.
This is particularly important for DialectTest, which tests that if the
dialect says a database CAN'T do a particular thing, then the database gives
an error confirming that it can't. So, if a future version of the database
improves, the test will fail, indicating that we can use that feature.
Looking at the test output, 3 failures is pretty good. The collation test is
a minor concern; probably the dialect needs to be fixed, but only really a
concern if you are sorting sets with null values of measures.
Julian
More information about the Mondrian
mailing list