[Mondrian] RE: Mondrian: Question about your change 8710

[Julian Hyde]

The cache is relational not dimensional - it works in terms of (column,
value) pairs rather then members - so it made sense to switch to a
relational constraint. I think we use dimensional constraints occasionally,
but I want to move away from that.

I had no idea that we were losing the caching. We should reinstate that. Can
you log a bug for that?

It starts me thinking - yet again - that we should have a performance
regression test. In this case, it would help to have a test which records
every single SQL statement executed for a particular query. We couldn't
maintain too many such tests, but a small number would help to raise flags
when something fundamental has changed.

Cc:ing the other developers in case they have some ideas.

Julian


> -----Original Message-----
> From: Rushan Chen [mailto:rchen at lucidera.com] 
> Sent: Wednesday, September 26, 2007 10:51 AM
> To: julianhyde at speakeasy.net
> Subject: Mondrian: Question about your change 8710
> 
> Hi Julian,
> 
> Recently I have been doing some comparison of generated SQLs 
> between two 
> mondrian versions we use here at LucidEra. The two versions are based 
> off the branches //open/lu/mondrian (call it Release A)and 
> //open/lu/release/mondrian/countzero(Release B)
> 
> One of the differences I noticed is the increased number of 
> this query  
> issued to optimize  column constraint  pushdown(into SQL) during 
> aggregate loading:
> 
> select count(distinct levelColumn) from  dimensionTable;
> 
> Previously in Release A, with the same connection, there will just be 
> one such query per dimension column; In release B, these queries are 
> repeated even for the same column. One of the reasons that 
> the result is 
> no longer cached is that the constraint type has changed from 
> MemberColumnConstraint to ValueColumnConstraint, which does not have 
> associated RolapLevel to cache the result into. This change 
> was made in 
> changelist 8710, to file RolapLevel.java(revision # 48, 
> search for "new 
> MemberColumnConstraint"). The code currently has a permanent "false" 
> condition so MemberColumnConstraint will never be used.
> 
> Can you recall the reason for this change? I am looking to 
> make caching 
> work again for column cardinality queries; and would like to 
> understand 
> what problems these changes in the past are trying to solve 
> so as not to 
> break anything.
> 
> Thanks,
> 
> Rushan
> 
> 
> 
> 
>