db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen <Oystein.Grov...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-937) Instability in wisconsin test
Date Fri, 30 Jun 2006 22:02:34 GMT
Mike Matrigali wrote:

> I was working under the assumption that the wisc diffs were the kinds of
> issues we had seen in the past.  Where the optimizer had 2 different 
> plans which were very close in costing, and due to slight differences in
> estimates one plan was chosen over another.

The exception in this case, if I have understood things correctly, is 
that one is not able to explain why there is a slight difference in 
estimates and why the fix solves the problem.  That is why I feel a JIRA 
should be filed to indicate that something else may be wrong here so 
that one remember to investigate this further.

> If anyone has done the careful analysis of the different plans and found 
> that there is a serious problem with the plans the optimizer was picking 
> please go ahead and report a new bug with that info and how to reproduce.

I have not done any careful analysis of the query plans, but as far as I 
have understood, before the fix, the test was as follows:

1. Create table
2. Insert data
3. Create indexes
4. Execute query

The problem was that not the same query plan was chosen every time. 
However, if you insert a compress between 3. and 4., the same query plan 
is chosen every time.  In other words, a compress may affect which plan 
is chosen.  You are saying that since the indexes is just created, a 
subsequent compress should not change estimates.  So what makes the plan 
change in that case?  I think it would be good to investigate that.

> My main concern was that spurious "expected" diffs means that almost 
> everyone is just going to ignore any real future bug the test might
> show up.

I totally agree that we needed to fix the test since it was failing so 
often and doing it this way is better than suspending the entire test. 
However, we should be aware that we are fixing the test without actually 
knowing whether the problem is really in the test or in the product.


View raw message