[
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.
