[
https://issues.apache.org/jira/browse/DERBY-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966542#action_12966542
]
Knut Anders Hatlen commented on DERBY-2949:
-------------------------------------------
It may be possible to improve the accuracy/predictability of the row count
estimate, but for this issue I think we should just try to make the test behave
predictably.
The test frequently executes the query "select count(c1) from flusher". The
comments say this about its purpose:
// Create and populate a table to be used for flushing the
// cache. Flushing the cache causes all row count changes to be
// written, which is necessary for the results of this test to
// be stable (because otherwise the row count changes would be
// written asynchronously)
It sounds like the query is meant to fill the page cache with new data,
evicting all pages currently in the cache, so that the row count changes are
written at a know point in time. So the net effect, at least with respect to
the row count estimate, should be the same as what we get from a checkpoint.
And it sounds like it was added in order to avoid exactly this kind of
intermittent failures.
However, I don't think the code works as intended because the FLUSHER table is
not big enough to flush all pages from the page cache. The table must be at
least as big as the page cache in order to achieve that, so the test needs to
increase the size of the table or reduce the size of the page cache (or both).
Alternatively, we could replace the selects from the FLUSHER table with
explicit checkpoints. I'm leaning towards the latter option (using checkpoints
to flush the estimates), since that sounds like the simpler one (no need to
know exact size of the page cache or the exact number of pages in the FLUSHER
table).
> 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
> Assignee: Knut Anders Hatlen
> 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.
