Return-Path: Delivered-To: apmail-db-derby-commits-archive@www.apache.org Received: (qmail 14204 invoked from network); 5 Aug 2009 17:08:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Aug 2009 17:08:23 -0000 Received: (qmail 37352 invoked by uid 500); 5 Aug 2009 17:08:30 -0000 Delivered-To: apmail-db-derby-commits-archive@db.apache.org Received: (qmail 37285 invoked by uid 500); 5 Aug 2009 17:08:30 -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 37274 invoked by uid 99); 5 Aug 2009 17:08:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Aug 2009 17:08:30 +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, 05 Aug 2009 17:08:28 +0000 Received: by eris.apache.org (Postfix, from userid 65534) id 069A72388895; Wed, 5 Aug 2009 17:08:08 +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, 05 Aug 2009 17:08:07 -0000 To: derby-commits@db.apache.org From: mikem@apache.org X-Mailer: svnmailer-1.0.8 Message-Id: <20090805170808.069A72388895@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Author: mikem Revision: 783168 Modified property: svn:log Modified: svn:log at Wed Aug 5 17:08:07 2009 ------------------------------------------------------------------------------ --- svn:log (original) +++ svn:log Wed Aug 5 17:08:07 2009 @@ -1,3 +1,5 @@ +DERBY-3926 + 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