db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3023) Different result rows depending on the sequence of INNER JOIN and OUTER JOIN
Date Sun, 21 Oct 2007 02:42:50 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536484
] 

A B commented on DERBY-3023:
----------------------------

I did some tracing through the execution-time result set processing for "new-style-sql.txt"
and while I still do not understand what is going on, I *think* that part of the problem is
that the two predicates for the outer-most query, i.e.:

  WHERE O4Work.ESVN01.NU_BUY_CPY = 99 AND O4Work.ESVNA0.NU_CPY_GRP = 0

are both being applied as "scan qualifiers" to the initial scans for ESVNB0 and ESVNE1, in
addition to being applied to their respective target tables.  That is to say, "NU_BUY_CPY
= 99" translates into a qualifier on the "first column" in ESVN01 (because NU_BUY_CPY is the
first column in that table); but further up the result set tree, that same qualifier is being
applied to the "first column" of ESVNB0 and (still later) to the "first column" of ESVNE1--which,
if that's what is actually happening, would be wrong...

Similarly, "NU_CPY_GRP = 0" translates into a qualifier on the "fourth column" of ESVNA0 (because
NU_CPY_GRP is the fourth column in that table); but later that same qualifier is being applied
to the "fourth column" of ESVNB0 and (still later) the "fourth column" of ESVNE1.

The reason the query returns the correct results (924 rows) if there is only one predicate,
"ESVN01.NU_BUY_CPY = 99", is because, as luck would have it, the first column in both ESVNB0
and ESVNE1 is *also* NU_CPY_GRP, and it, like ESVN01, has the value 99 for all rows.  So even
though the predicate is (apparently) mis-applied, it doesn't affect the results because it
doesn't actually filter any rows.

But the second predicate, "ESVNA0.NU_CPY_GRP = 0", does affect the results because the fourth
column of ESVNB0 and ESVNE1 is "NU_MT1_CPY", and that column does not have any rows with value
"0".  So when the predicate is mis-applied to ESVNB0, it eliminates all of ESVNB0's rows,
thus causing the query to return no results.

In an attempt to validate this somewhat bizarre theory, I updated a few of the rows in ESVNB0
to have the value "0" for column NU_MT1_CPY:

  update o4work.esvnb0 set nu_mt1_cpy = 0 where nu_mt1_cpy = 2;

When I re-ran "new-style-sql.txt", the query still returned 0 rows.  Further tracing showed
that we were now getting some rows back from ESVNB0, but then we were joining them with ESVNE1--and
since ESVNE1 still didn't have any NU_MT1_CPY columns with value 0, we were filtering out
all of ESVNE1's rows, leading to an empty result set.  So I then updated ESVNE1 in a way similar
to ESVNB0, ie:

  update o4work.esvne1 set nu_mt1_cpy = 0 where nu_mt1_cpy = 2;

When I did that, "new-style-sql.txt" returned 906 rows.  This seems to suggest (though it's
far from conclusive) that the NU_CPY_GRP qualifier is being mis-applied in the hash scans
for ESVNB0 and ESNB1.

A look at the query plans for "new-style-sql_without-condition.txt" and "new-style-sql.txt"
seems to suggest a similar thing.  Note in particular the scan qualifiers for the hash scans
on ESVNB0 and ESVNE1.  For "new-style-sql_without-condition", we see a single scan qualifier
on the first column:

 scan qualifiers:
 Column[0][0] Id: 0
 Operator: =
 Ordered nulls: false
 Unknown return value: false
 Negate comparison result: false

This corresponds to "NU_BUY_CPY = 99" (verified by tracing, where the qualifier value is '99'),
which is always true for all rows of ESVNB0 and ESVNE1.  But for "new-style-sql.txt", we see
*two* scan qualifiers:

 scan qualifiers:
 Column[0][0] Id: 0
 Operator: =
 Ordered nulls: false
 Unknown return value: false
 Negate comparison result: false

 Column[0][1] Id: 3
 Operator: =
 Ordered nulls: false
 Unknown return value: false
 Negate comparison result: false

The second qualifier is on the fourth column and has a value of '0', which appears to be coming
from the "NU_CPY_GRP = 0" predicate.  That qualifier is eliminating all rows from the scans
(for both ESVNB0 and ESVNE1), leading to zero results.

Given this potentially erroneus theory, it appears that somehow the qualifiers for the outer-most
WHERE clause are being mapped incorrectly onto ESVNB0 and ESVNE1.  Maybe this is a transitive
closure computation problem, maybe it's something else entirely.  At this point I don't know,
I'm just dumping what I've seen thus far...


> Different result rows depending on the sequence of INNER JOIN and OUTER JOIN
> ----------------------------------------------------------------------------
>
>                 Key: DERBY-3023
>                 URL: https://issues.apache.org/jira/browse/DERBY-3023
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4
>         Environment: Windows XP, Java 1.4.2
>            Reporter: Stefan Cordes
>         Attachments: derby-02-search-joins.zip, derby-02-search-joins2.zip, RUNTIMESTATISTICS-10.3.zip,
Statement10.3.1.4 - (561794)-j1.4.2_10.zip
>
>
> We have a complex SQL joining 11 Tables via INNER JOIN and OUTER JOIN.
> These SQLs were tested against an z/OS DB2 Version 8.
> After moving to our local platform with Derby we found out the resultsets returned by
the SQLs were too less.
> I tested our "old style" SQL which results in 889 rows.
> Our new style SQL expected to give similar rows but gives *0*.
> After some work we found a workaround: first place all the "INNER JOIN"s in the SQL and
then the "OUTER JOIN"s.
> {code:title=Result of testprogram}
> Derby=10.3-b561794
> Test 10.3-b561794-old-style-sql
> 889 Rows in 1703ms
> Test 10.3-b561794-new-style-sql
> 0 Rows in 563ms  _(expected 924 rows instead)_
> Test 10.3-b561794-new-style-sql-only-inner
> 2 Rows in 766ms _(only inner joins, no outer joins but larger result)_
> Test 10.3-b561794-new-style-sql_first-inner-joins
> 924 Rows in 578ms
> Test 10.3-b561794-new-style-sql_without-condition
> 924 Rows in 438ms
> {code}
> Here our initial used SQL:
> {code:title=SQL giving wrong result (0 rows)}
> SELECT O4Work.ESVN01.NU_BUY_CPY AS PO_BuyCompanyNo, O4Work.ESVN01.NU_ODR AS PO_Number,
O4Work.ESVN01.FL_ODR_CAE AS PO_Type, O4Work.ESVN01.NU_MCS_SPY AS PO_SupplierNo, O4Work.ESVN01.NU_ST3
AS PO_StatusNo, O4Work.ESVN01.DA_SPY_COY_PRT AS PO_SCPrintDate, O4Work.ESVN01.FL_SAS AS PO_SeasFlag,
CASE WHEN (SELECT COUNT(O4Work.ESVNA5.ID_PTE) FROM O4Work.ESVNA5 WHERE O4Work.ESVN02.NU_BUY_CPY
= O4Work.ESVNA5.NU_BUY_CPY AND O4Work.ESVN02.NU_ODR = O4Work.ESVNA5.NU_ODR AND O4Work.ESVN02.NU_PST
= O4Work.ESVNA5.NU_PST) = 0 THEN 'N' ELSE 'Y' END AS POPA_PictureID, CASE WHEN (SELECT COUNT(O4Work.ESVNG3.NU_ODR)
FROM O4Work.ESVNG3 WHERE O4Work.ESVN01.NU_BUY_CPY = O4Work.ESVNG3.NU_BUY_CPY AND O4Work.ESVN01.NU_ODR
= O4Work.ESVNG3.NU_ODR) = 0 THEN 'N' ELSE 'Y' END AS ON_ID, O4Work.ESVN02.NU_PST AS POP_Position_Id,
O4Work.ESVN02.NU_CTT AS POP_ContractNo, O4Work.ESVN02.NU_ARO_CTT AS POP_ArosContractNo, O4Work.ESVN02.NU_ST3
AS POP_StatusNo, O4Work.ESVN02.DA_CAE AS POP_CreationDate, O4Work.ESVN02.DA_LAT_AMD AS POP_LastAmendDate,
O4Work.ESVNA0.NU_SSN_IDE AS POPD_SeasonInd,  O4Work.ESVNA0.NU_STL_ID1 AS POPD_StyleId, O4Work.ESVNA0.NU_SRY_ID1
AS POPD_StoryID, O4Work.ESVNA0.NU_LC1 AS POPD_LicenseID, O4Work.ESVP00.NU_CSY AS SER_ClassNo,
O4Work.ESVP00.NU_COE AS SER_CodeNo, O4Work.ESVP00.NU_SRL AS SER_SerialNo, O4Work.ESVP00.NU_PIK_MOD
AS SER_PickingM, O4Work.ESVN03.NU_MT1_CPY AS POPC_MasterCpyNo, O4Work.ESVN03.QU_ODR AS POPC_OrderedQty,
O4Work.ESVN03.DA_EDD AS POPC_Edd, O4Work.ESVN03.DA_LDD AS POPC_Ldd, O4Work.ESVN03.DA_PAD AS
POPC_Pad, O4Work.ESVN03.DA_SAD AS POPC_Sad, O4Work.ESVN03.PR_SCP AS POPC_SupCstPrice, O4Work.ESVN03.NU_SCP_CR1
AS POPC_SupCstPrCurr, O4Work.ESVN03.NU_ST3 AS POPC_StatusNo, O4Work.ESVN03.NU_COY_FRM_ODR
AS POPC_Src_PO_Number, O4Work.ESVN03.NU_COY_UTL_ODR AS POPC_Tgt_PO_Number, O4Work.ESVN03.DA_FLR_RDY
AS POPC_FRM_DATE, O4Work.ESVN03.FL_CSG AS POPC_CS_FLAG, O4Work.ESVN03.NU_PAK_MOD_SPY AS POPC_PackSupplNo,
O4Work.ESVN03.NU_PAK_MOD_DCR AS POPC_PackingDCNo, O4Work.ESVN03.NU_PS2_MOD AS POPC_PresMethodNo,
O4Work.ESVN04.NU_RTL_CPY AS POPRC_RetailCode, O4Work.ESVN04.PR_PLN_SEL AS POPRC_SellPrice,
O4Work.ESVN04.NU_PLN_SEL_PRC_CR1 AS POPRC_SellPrCurr, O4Work.ESVN08.NU_AVE AS POPRCA_AdvertNo,
O4Work.ESVQ00.ID_SHP AS SHP_ShippingID, O4Work.ESVQ00.NU_SHP AS SHP_ShippingNo, O4Work.ESVNB0.NU_NTL_PDE_ID1
AS POPDC_NationalID, O4Work.ESVNB0.NU_EQP AS POPDC_EquipNumber, O4Work.ESVNE1.PE_OMU AS POPCC_OMU,
CASE WHEN (SELECT COUNT(O4Work.ESVN07.NU_ODR) FROM O4Work.ESVN07 WHERE O4Work.ESVN03.NU_BUY_CPY
= O4Work.ESVN07.NU_BUY_CPY AND O4Work.ESVN03.NU_MT1_CPY = O4Work.ESVN07.NU_MT1_CPY AND O4Work.ESVN03.NU_ODR
= O4Work.ESVN07.NU_ODR AND O4Work.ESVN03.NU_PST = O4Work.ESVN07.NU_PST AND O4Work.ESVN07.FL_ALE_RMK
= 'Y') = 0 THEN 'N' ELSE 'Y' END AS POPCU_AllocRem FROM O4Work.ESVN02 
> INNER JOIN O4Work.ESVN01 ON O4Work.ESVN02.NU_BUY_CPY = O4Work.ESVN01.NU_BUY_CPY AND O4Work.ESVN02.NU_ODR
= O4Work.ESVN01.NU_ODR 
> INNER JOIN O4Work.ESVNA0 ON O4Work.ESVN02.NU_BUY_CPY = O4Work.ESVNA0.NU_BUY_CPY AND O4Work.ESVN02.NU_ODR
= O4Work.ESVNA0.NU_ODR AND O4Work.ESVN02.NU_PST = O4Work.ESVNA0.NU_PST 
> INNER JOIN O4Work.ESVP00 ON O4Work.ESVNA0.ID_SRL = O4Work.ESVP00.ID_SRL 
> LEFT OUTER JOIN O4Work.ESVNA4 ON O4Work.ESVNA0.NU_BUY_CPY = O4Work.ESVNA4.NU_BUY_CPY
AND O4Work.ESVNA0.NU_ODR = O4Work.ESVNA4.NU_ODR AND O4Work.ESVNA0.NU_PST = O4Work.ESVNA4.NU_PST

> INNER JOIN O4Work.ESVN03 ON O4Work.ESVN02.NU_BUY_CPY = O4Work.ESVN03.NU_BUY_CPY AND O4Work.ESVN02.NU_ODR
= O4Work.ESVN03.NU_ODR AND O4Work.ESVN02.NU_PST = O4Work.ESVN03.NU_PST 
> LEFT OUTER JOIN O4Work.ESVN04 ON O4Work.ESVN03.NU_BUY_CPY = O4Work.ESVN04.NU_BUY_CPY
AND O4Work.ESVN03.NU_MT1_CPY = O4Work.ESVN04.NU_MT1_CPY AND O4Work.ESVN03.NU_ODR = O4Work.ESVN04.NU_ODR
AND O4Work.ESVN03.NU_PST = O4Work.ESVN04.NU_PST 
> LEFT OUTER JOIN O4Work.ESVN08 ON O4Work.ESVN04.NU_BUY_CPY = O4Work.ESVN08.NU_BUY_CPY
AND O4Work.ESVN04.NU_RTL_CPY = O4Work.ESVN08.NU_RTL_CPY AND O4Work.ESVN04.NU_MT1_CPY = O4Work.ESVN08.NU_MT1_CPY
AND O4Work.ESVN04.NU_ODR = O4Work.ESVN08.NU_ODR AND O4Work.ESVN04.NU_PST = O4Work.ESVN08.NU_PST

> INNER JOIN O4Work.ESVQ00 ON O4Work.ESVN03.ID_SHP = O4Work.ESVQ00.ID_SHP 
> INNER JOIN O4Work.ESVNB0 ON O4Work.ESVN03.NU_BUY_CPY = O4Work.ESVNB0.NU_BUY_CPY AND O4Work.ESVN03.NU_MT1_CPY
= O4Work.ESVNB0.NU_MT1_CPY AND O4Work.ESVN03.NU_ODR = O4Work.ESVNB0.NU_ODR AND O4Work.ESVN03.NU_PST
= O4Work.ESVNB0.NU_PST 
> INNER JOIN O4Work.ESVNE1 ON O4Work.ESVN03.NU_BUY_CPY = O4Work.ESVNE1.NU_BUY_CPY AND O4Work.ESVN03.NU_MT1_CPY
= O4Work.ESVNE1.NU_MT1_CPY AND O4Work.ESVN03.NU_ODR = O4Work.ESVNE1.NU_ODR AND O4Work.ESVN03.NU_PST
= O4Work.ESVNE1.NU_PST 
> WHERE O4Work.ESVN01.NU_BUY_CPY = 99 AND O4Work.ESVNA0.NU_CPY_GRP = 0
> {code}
> and the one with moved inner joins:
> {code:title=SQL giving correct result (924 rows)}
> SELECT O4Work.ESVN01.NU_BUY_CPY AS PO_BuyCompanyNo, O4Work.ESVN01.NU_ODR AS PO_Number,
O4Work.ESVN01.FL_ODR_CAE AS PO_Type, O4Work.ESVN01.NU_MCS_SPY AS PO_SupplierNo, O4Work.ESVN01.NU_ST3
AS PO_StatusNo, O4Work.ESVN01.DA_SPY_COY_PRT AS PO_SCPrintDate, O4Work.ESVN01.FL_SAS AS PO_SeasFlag,
CASE WHEN (SELECT COUNT(O4Work.ESVNA5.ID_PTE) FROM O4Work.ESVNA5 WHERE O4Work.ESVN02.NU_BUY_CPY
= O4Work.ESVNA5.NU_BUY_CPY AND O4Work.ESVN02.NU_ODR = O4Work.ESVNA5.NU_ODR AND O4Work.ESVN02.NU_PST
= O4Work.ESVNA5.NU_PST) = 0 THEN 'N' ELSE 'Y' END AS POPA_PictureID, CASE WHEN (SELECT COUNT(O4Work.ESVNG3.NU_ODR)
FROM O4Work.ESVNG3 WHERE O4Work.ESVN01.NU_BUY_CPY = O4Work.ESVNG3.NU_BUY_CPY AND O4Work.ESVN01.NU_ODR
= O4Work.ESVNG3.NU_ODR) = 0 THEN 'N' ELSE 'Y' END AS ON_ID, O4Work.ESVN02.NU_PST AS POP_Position_Id,
O4Work.ESVN02.NU_CTT AS POP_ContractNo, O4Work.ESVN02.NU_ARO_CTT AS POP_ArosContractNo, O4Work.ESVN02.NU_ST3
AS POP_StatusNo, O4Work.ESVN02.DA_CAE AS POP_CreationDate, O4Work.ESVN02.DA_LAT_AMD AS POP_LastAmendDate,
O4Work.ESVNA0.NU_SSN_IDE AS POPD_SeasonInd,  O4Work.ESVNA0.NU_STL_ID1 AS POPD_StyleId, O4Work.ESVNA0.NU_SRY_ID1
AS POPD_StoryID, O4Work.ESVNA0.NU_LC1 AS POPD_LicenseID, O4Work.ESVP00.NU_CSY AS SER_ClassNo,
O4Work.ESVP00.NU_COE AS SER_CodeNo, O4Work.ESVP00.NU_SRL AS SER_SerialNo, O4Work.ESVP00.NU_PIK_MOD
AS SER_PickingM, O4Work.ESVN03.NU_MT1_CPY AS POPC_MasterCpyNo, O4Work.ESVN03.QU_ODR AS POPC_OrderedQty,
O4Work.ESVN03.DA_EDD AS POPC_Edd, O4Work.ESVN03.DA_LDD AS POPC_Ldd, O4Work.ESVN03.DA_PAD AS
POPC_Pad, O4Work.ESVN03.DA_SAD AS POPC_Sad, O4Work.ESVN03.PR_SCP AS POPC_SupCstPrice, O4Work.ESVN03.NU_SCP_CR1
AS POPC_SupCstPrCurr, O4Work.ESVN03.NU_ST3 AS POPC_StatusNo, O4Work.ESVN03.NU_COY_FRM_ODR
AS POPC_Src_PO_Number, O4Work.ESVN03.NU_COY_UTL_ODR AS POPC_Tgt_PO_Number, O4Work.ESVN03.DA_FLR_RDY
AS POPC_FRM_DATE, O4Work.ESVN03.FL_CSG AS POPC_CS_FLAG, O4Work.ESVN03.NU_PAK_MOD_SPY AS POPC_PackSupplNo,
O4Work.ESVN03.NU_PAK_MOD_DCR AS POPC_PackingDCNo, O4Work.ESVN03.NU_PS2_MOD AS POPC_PresMethodNo,
O4Work.ESVN04.NU_RTL_CPY AS POPRC_RetailCode, O4Work.ESVN04.PR_PLN_SEL AS POPRC_SellPrice,
O4Work.ESVN04.NU_PLN_SEL_PRC_CR1 AS POPRC_SellPrCurr, O4Work.ESVN08.NU_AVE AS POPRCA_AdvertNo,
O4Work.ESVQ00.ID_SHP AS SHP_ShippingID, O4Work.ESVQ00.NU_SHP AS SHP_ShippingNo, O4Work.ESVNB0.NU_NTL_PDE_ID1
AS POPDC_NationalID, O4Work.ESVNB0.NU_EQP AS POPDC_EquipNumber, O4Work.ESVNE1.PE_OMU AS POPCC_OMU,
CASE WHEN (SELECT COUNT(O4Work.ESVN07.NU_ODR) FROM O4Work.ESVN07 WHERE O4Work.ESVN03.NU_BUY_CPY
= O4Work.ESVN07.NU_BUY_CPY AND O4Work.ESVN03.NU_MT1_CPY = O4Work.ESVN07.NU_MT1_CPY AND O4Work.ESVN03.NU_ODR
= O4Work.ESVN07.NU_ODR AND O4Work.ESVN03.NU_PST = O4Work.ESVN07.NU_PST AND O4Work.ESVN07.FL_ALE_RMK
= 'Y') = 0 THEN 'N' ELSE 'Y' END AS POPCU_AllocRem FROM O4Work.ESVN02 
> INNER JOIN O4Work.ESVN01 ON O4Work.ESVN02.NU_BUY_CPY = O4Work.ESVN01.NU_BUY_CPY AND O4Work.ESVN02.NU_ODR
= O4Work.ESVN01.NU_ODR 
> INNER JOIN O4Work.ESVNA0 ON O4Work.ESVN02.NU_BUY_CPY = O4Work.ESVNA0.NU_BUY_CPY AND O4Work.ESVN02.NU_ODR
= O4Work.ESVNA0.NU_ODR AND O4Work.ESVN02.NU_PST = O4Work.ESVNA0.NU_PST 
> INNER JOIN O4Work.ESVP00 ON O4Work.ESVNA0.ID_SRL = O4Work.ESVP00.ID_SRL 
> INNER JOIN O4Work.ESVN03 ON O4Work.ESVN02.NU_BUY_CPY = O4Work.ESVN03.NU_BUY_CPY AND O4Work.ESVN02.NU_ODR
= O4Work.ESVN03.NU_ODR AND O4Work.ESVN02.NU_PST = O4Work.ESVN03.NU_PST 
> INNER JOIN O4Work.ESVNB0 ON O4Work.ESVN03.NU_BUY_CPY = O4Work.ESVNB0.NU_BUY_CPY AND O4Work.ESVN03.NU_MT1_CPY
= O4Work.ESVNB0.NU_MT1_CPY AND O4Work.ESVN03.NU_ODR = O4Work.ESVNB0.NU_ODR AND O4Work.ESVN03.NU_PST
= O4Work.ESVNB0.NU_PST 
> INNER JOIN O4Work.ESVQ00 ON O4Work.ESVN03.ID_SHP = O4Work.ESVQ00.ID_SHP 
> LEFT OUTER JOIN O4Work.ESVNA4 ON O4Work.ESVNA0.NU_BUY_CPY = O4Work.ESVNA4.NU_BUY_CPY
AND O4Work.ESVNA0.NU_ODR = O4Work.ESVNA4.NU_ODR AND O4Work.ESVNA0.NU_PST = O4Work.ESVNA4.NU_PST

> LEFT OUTER JOIN O4Work.ESVN04 ON O4Work.ESVN03.NU_BUY_CPY = O4Work.ESVN04.NU_BUY_CPY
AND O4Work.ESVN03.NU_MT1_CPY = O4Work.ESVN04.NU_MT1_CPY AND O4Work.ESVN03.NU_ODR = O4Work.ESVN04.NU_ODR
AND O4Work.ESVN03.NU_PST = O4Work.ESVN04.NU_PST 
> LEFT OUTER JOIN O4Work.ESVN08 ON O4Work.ESVN04.NU_BUY_CPY = O4Work.ESVN08.NU_BUY_CPY
AND O4Work.ESVN04.NU_RTL_CPY = O4Work.ESVN08.NU_RTL_CPY AND O4Work.ESVN04.NU_MT1_CPY = O4Work.ESVN08.NU_MT1_CPY
AND O4Work.ESVN04.NU_ODR = O4Work.ESVN08.NU_ODR AND O4Work.ESVN04.NU_PST = O4Work.ESVN08.NU_PST

> INNER JOIN O4Work.ESVNE1 ON O4Work.ESVN03.NU_BUY_CPY = O4Work.ESVNE1.NU_BUY_CPY AND O4Work.ESVN03.NU_MT1_CPY
= O4Work.ESVNE1.NU_MT1_CPY AND O4Work.ESVN03.NU_ODR = O4Work.ESVNE1.NU_ODR AND O4Work.ESVN03.NU_PST
= O4Work.ESVNE1.NU_PST 
> WHERE O4Work.ESVN01.NU_BUY_CPY = 99 AND O4Work.ESVNA0.NU_CPY_GRP = 0
> {code}
> Another curious behavior is that leaving out the condition {{O4Work.ESVNA0.NU_CPY_GRP
= 0}} in the first SQL will give us the result of 924 all having O4Work.ESVNA0.NU_CPY_GRP
= 0. So evaluation of the condition is buggy, too.
> I think there may be a dependency between this issue and these ones:
> [DERBY-1681|http://issues.apache.org/jira/browse/DERBY-1681] (Regression (wrong results):
Join predicate can be ignored for left-most child in a chain of nested unions.)
> [DERBY-1633|https://issues.apache.org/jira/browse/DERBY-1633] (Regression: The fields
of views are not being calculated properly since 10.1.2.4)
> Attached is an Eclipse project with the Test-Program (without the Derby-Libraries) and
the several RUNTIMESTATISTICS.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message