[
https://issues.apache.org/jira/browse/DERBY-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966042#action_12966042
]
Knut Anders Hatlen commented on DERBY-2949:
-------------------------------------------
I see that if I call SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE right before the loop
that performs the last 11 executions of the query, the assert fails
consistently. I'm not sure exactly how the checkpoint interacts with the
optimizer, though. Perhaps it's doing something with the row count estimates?
The reason why I tried adding a checkpoint at that point in the code, was that
the test sets derby.storage.checkpointInterval=100000. There aren't any
comments saying why it does that, neither in StalePlansTest nor in the original
staleplans.sql, but I suppose it is to make the checkpoints happen at the spots
where it's known to be safe and/or needed.
I also see that the assert fails consistently if I effectively disable
checkpointing for the test by setting derby.storage.checkpointInterval to the
maximum allowed value (128*1024*1024). If I run the test with the default
settings, I see that the background worker thread invokes a checkpoint when
testStalePlansOnLargeTable has loaded the rows into the table. I suppose,
depending on timing, this checkpoint could end up running at a time where it
interferes with the optimizer's decisions.
Would it make sense to disable automatic checkpointing for the test and add a
call to SYSCS_CHECKPOINT_DATABASE after the table has been populated? Then at
least we know that the checkpoint has been performed at the expected spot, and
that it has completed before we start executing the statements whose plans we
want to check.
And if someone could shed some light on *why* the checkpoint affects the
choices of the optimizer, that would be appreciated too... :)
> AssertionFailedError in testStalePlansOnLargeTable
> --------------------------------------------------
>
> Key: DERBY-2949
> URL: https://issues.apache.org/jira/browse/DERBY-2949
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.3.1.4
> Environment: Microsoft© Windows VistaT Ultimate - 6.0.6000 N/A Build
> 6000
> WindowsNT 0 6
> 2 X [Sun Fire X4100 Server x64 Family 15 Model 37 Stepping 1 AuthenticAMD]:
> ~2592 MHz, cache. 3ÿ967 Total Memory.
> JVM: Sun Microsystems Inc. 1.5.0_07-b03
> Reporter: Henri van de Scheur
> Priority: Minor
> Attachments: expected-plan.txt, plan.txt
>
>
> testStalePlansOnLargeTable(org.apache.derbyTesting.functionTests.tests.lang.StalePlansTest)junit.framework.AssertionFailedError
> at
> org.apache.derbyTesting.functionTests.tests.lang.StalePlansTest.testStalePlansOnLargeTable(StalePlansTest.java:264)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:88)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
