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-3819) 'Expected Table Scan ResultSet for T3' in 'test_predicatePushdown(....PredicatePushdownTest)' since 670215 2008-06-21 18:01:08 MEST
Date Wed, 06 Aug 2008 19:18:46 GMT

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


Mime
View raw message