Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44161F2E.8030605@sbcglobal.net>
Date: Mon, 13 Mar 2006 17:41:02 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
Reply-To: mikem_app@sbcglobal.net
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [jira] Commented: (DERBY-1109) lang/predicatePushdown.sql fails
 with wsdd5.6
References: <2098589374.1142298294956.JavaMail.jira@ajax>
In-Reply-To: <2098589374.1142298294956.JavaMail.jira@ajax>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Is there any hash joins in this plan? That is the standard reason to see 
different ordering on different jvm/machine if plans look the same.

A B (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1109?page=comments#action_12370278 ] 
> 
> A B commented on DERBY-1109:
> ----------------------------
> 
> This issue is the same as DERBY-1110--they both have the same query in them, and that query is failing with the same row-ordering diff.
> 
> This diff is an interesting one: I've verified that for IBM wsdd the optimizer chooses the same join order that it chooses for all other JVMs--which is expected since the derby.optimizer.noTimeout flag is set to "true" for both lang/subquery.sql and lang/predicatePushdown.sql, and thus the optimizer should always choose the same plan, regardless of machine/platform.
> 
> That said, I'm not sure what could be causing this specific difference in row ordering for IBM wsdd.  I am able to reproduce the diff on my machine,  but don't understand where it comes from.  Since the optimizer is choosing the same join order for all platforms, I was assuming the row order should be the same, as well--but that's apparently not a safe assumption.  I did notice that the queries that are failing have "DISTINCT" in them, so it's possible that the ordering of rows based on a DISTINCT is JVM-dependent somehow, which would explain this diff.
> 
> Can anyone confirm that one way or the other?
> 
> If this is just an _acceptable_ difference in JVM behavior, then there are two possible solutions here: either 1) create a wsdd-specific master, or 2) (and probably more preferably) add an "order by" clause to the queries in question to ensure that we get the same row order across JVMs.
> 
> If, however, this difference in row order seems like incorrect behavior, then this would of course merit further investigation.
> 
> Anyone have any input one way or the other?
> 
> 
>>lang/predicatePushdown.sql fails with wsdd5.6
>>---------------------------------------------
>>
>>         Key: DERBY-1109
>>         URL: http://issues.apache.org/jira/browse/DERBY-1109
>>     Project: Derby
>>        Type: Test
>>  Components: Regression Test Failure
>>    Versions: 10.2.0.0
>> Environment: IBM wsdd5.6 j9_13
>>    Reporter: Deepa Remesh
> 
> 
>>This test fails with the following diff:
>>7507a7508,7509
>>
>>>2          |1          
>>>4          |2          
>>
>>7509,7510d7510
>>< 4          |2          
>>< 2          |1          
>>7632a7633,7636
>>
>>>2          |1          
>>>2          |1          
>>>4          |2          
>>>4          |2          
>>
>>7635,7638d7638
>>< 4          |2          
>>< 4          |2          
>>< 2          |1          
>>< 2          |1     
> 
>