db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lily Wei <lily...@yahoo.com>
Subject Re: (DERBY-4908) Instability in CheckConstraintTest.testBuiltInFunctions
Date Sat, 20 Nov 2010 00:41:23 GMT
> Bryan Pendleton <bpendleton.derby@gmail.com> writes:
>
> <good explanation of optimizer workings>
>
> Doesn't this still leave the question why the test is unstable?: What
> could make the optimizer choice vary from test run to test run? I can
> think of the maximum time the optimizer would spend before it gives up
> looking for further plans, and that this could lead to different choice
> depending on machine performance, load etc. Does this test involve a
> large join? 

I don't think the join is large, but the query that gets the unexpected
result is indeed a join:

        rs = st.executeQuery(
            " select  c.type from "
            + "sys.sysconstraints c, sys.systables t where "
            + "c.tableid = t.tableid and tablename='T1'");

I'm not 100% sure the failure was caused by wrong ordering, though,
since assertFullResultSet only reports the first mismatch it
finds. Perhaps it would be a good improvement to get assertFullResultSet
to dump the full result on a mismatch?

> If not, what else could make the optimizer choice non-predictable?

I think the memory footprint and the available memory are also used to
determine the cost of a hash scan (if it doesn't fit in main memory, it
will be considered more expensive).

I would think the full result set will be nice to have. Test optimizer on the 
path choosing based on row size, memory size and else will be great as well.

Lily


      
Mime
View raw message