Return-Path: Delivered-To: apmail-db-derby-commits-archive@www.apache.org Received: (qmail 60810 invoked from network); 10 Jun 2009 04:16:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 10 Jun 2009 04:16:28 -0000 Received: (qmail 60079 invoked by uid 500); 10 Jun 2009 04:16:40 -0000 Delivered-To: apmail-db-derby-commits-archive@db.apache.org Received: (qmail 60009 invoked by uid 500); 10 Jun 2009 04:16:40 -0000 Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Derby Development" List-Id: Delivered-To: mailing list derby-commits@db.apache.org Received: (qmail 60000 invoked by uid 99); 10 Jun 2009 04:16:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jun 2009 04:16:40 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jun 2009 04:16:38 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id EA60F238888D; Wed, 10 Jun 2009 04:16:17 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn propchange: r783168 - svn:log Date: Wed, 10 Jun 2009 04:16:17 -0000 To: derby-commits@db.apache.org From: mamta@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20090610041617.EA60F238888D@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: mamta Revision: 783168 Modified property: svn:log Modified: svn:log at Wed Jun 10 04:16:17 2009 ------------------------------------------------------------------------------ --- svn:log (original) +++ svn:log Wed Jun 10 04:16:17 2009 @@ -1,4 +1,4 @@ -Following is the patch description. +Following is the patch description for DERBY-3926. The problem with the trunk codeline is that when optimizer goes through optimizables in a join order, it only looks at those optimizables individually to decide whether sorting can be avoided on them or not. That approach leaves out few queries which require sorting but do not get sorted. The decision for avoiding sorting should also include relationship between the optimizables in a given join order. Following query demonstrates the trunk problem SELECT table1.id, table2.value, table3.value FROM --DERBY-PROPERTIES joinOrder=FIXED table3 -- DERBY-PROPERTIES index=nonUniqueOnValue_Table3