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.
--
Øystein
