From derby-dev-return-62419-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Wed Aug 06 19:19:47 2008 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 64500 invoked from network); 6 Aug 2008 19:19:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Aug 2008 19:19:45 -0000 Received: (qmail 13192 invoked by uid 500); 6 Aug 2008 19:19:45 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 12975 invoked by uid 500); 6 Aug 2008 19:19:44 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 12964 invoked by uid 99); 6 Aug 2008 19:19:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Aug 2008 12:19:44 -0700 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.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Aug 2008 19:18:49 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 70BD5234C1A2 for ; Wed, 6 Aug 2008 12:18:46 -0700 (PDT) Message-ID: <722539782.1218050326460.JavaMail.jira@brutus> Date: Wed, 6 Aug 2008 12:18:46 -0700 (PDT) From: "A B (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-3819) 'Expected Table Scan ResultSet for T3' in 'test_predicatePushdown(....PredicatePushdownTest)' since 670215 2008-06-21 18:01:08 MEST In-Reply-To: <980453294.1217940764735.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620391#action_12620391 ] A B commented on DERBY-3819: ---------------------------- > I'm not sure if the new plan is ok or not. The test comments preceding the point of failure (line 1139) say: // Predicate push-down should occur for next two queries. Thus // we we should see Index scans for T3 and T4--and this should be // the case regardless of the order of the FROM list. So the test case is specifically expecting pushdown to happen; the fact that you're seeing a Table Scan instead of an Index Scan comes from the fact that the optimizer has now determined that it's cheaper to do a hash join than a nested loop join, and predicates don't get pushed for hash joins. Since we don't push the predicate we end up with a table scan. Similarly, the test comments preceding the original failure reported in this issue say (line 1373): // In this query the optimizer will consider pushing, but // will find that it's cheaper to do a hash join and thus // will _not_ push. So we see hash join with table scan on T3. Apparently running with "-d64" makes the optimizer's estimate change: either the hash join estimate goes up or the nested loop estimate (with predicate pushdown) goes down. Either way we end up pushing the predicate instead of doing a hash join, so we fail. In general, the test cases for PredicatePushdown were created based on the behavior/estimates seen at the time of writing, and were written with the assumption that the optimizer would make the same decisions on all machines given a noTimeout value of "true". But that assumption was wrong, esp. in the case of refSize, which varies from machine to machine (esp. 32-bit vs 64 bit). So I'm not sure how to go about resolving these issues; it seems quite likely that, as Kathey found out, making hardcoded tweaks here and there to maxMemoryPerTable might fix one problem but lead to another (if not on the same machine then perhaps on a different one). I wonder if the test harness could figure out if the machine is 32-bit vs 64-bit and then adjust maxMemoryPerTable accordingly? Not sure if there's a reliable way to make that adjustment, but there might be...? > 'Expected Table Scan ResultSet for T3' in 'test_predicatePushdown(....PredicatePushdownTest)' since 670215 2008-06-21 18:01:08 MEST > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-3819 > URL: https://issues.apache.org/jira/browse/DERBY-3819 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure > Affects Versions: 10.5.0.0 > Environment: OS: Solaris 10 5/08 s10x_u5wos_10 X86 64bits - SunOS 5.10 Generic_127128-11 (sol) > JVM: Sun Microsystems Inc. > java version "1.6.0_06" > Java(TM) SE Runtime Environment (build 1.6.0_06-b02) > Java HotSpot(TM) 64-Bit Server VM (build 10.0-b22 mixed mode 64-bit) > Reporter: Ole Solberg > Assignee: Kathey Marsden > Attachments: new_plan.txt, old_plan.txt > > > 'test_predicatePushdown(org.apache.derbyTesting.functionTests.tests.lang.PredicatePushdownTest)junit.framework.AssertionFailedError: Expected Table Scan ResultSet for T3' since 670215 2008-06-21 18:01:08 MEST http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/670215.txt > The failure is seen on SunOS 5.10 / Sun Jvm 1.6.0. > See e.g. http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/testlog/sol/682186-suitesAll_diff.txt > The test (suites.All) is run with '-XX:-UseThreadPriorities -XX:MaxPermSize=128M -Xmx256M -d64'. > When run with '-XX:MaxPermSize=128M -Xmx256M' as is used for the other platforms in this set of tests we do not see a failure. > The failure was also seen on Solaris Express Community Edition snv_86 X86bits - SunOS 5.11 snv_86 (solN+1) between 670215 and 676638. > (Run w/ -XX:-UseThreadPriorities -XX:MaxPermSize=128M -Xmx256M -d32) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.