[
https://issues.apache.org/jira/browse/DERBY-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966202#action_12966202
]
Knut Anders Hatlen commented on DERBY-2949:
-------------------------------------------
Kristian gave me some hints as to where to look... Thanks!
It looks like we have two mechanisms for updating the row count estimate:
1) Full table scans will set the correct row count when they complete.
2) When a dirty page is written to disk (for example in a checkpoint) the row
count estimate is updated with the delta between the current row count and the
row count at the time the page was last read from or written to disk.
But those two mechanisms don't know about each other, so when we're adding a
delta to the estimate while writing the page, that delta may include rows that
have already been accounted for by a full table scan, and those changes will
end up being applied twice to the estimate.
For example I see this when accessing a table that contains 10000 rows:
1. First do SELECT COUNT(*) FROM T, and the row count will be correctly set to
10000
2. Delete every other row in the table (DELETE FROM T WHERE MOD(ID, 2) = 0),
the row count estimate won't be changed
3. Do SELECT COUNT(*) FROM T again, and the estimate will be changed to 5000
(which is correct)
4. Invoke a checkpoint, which will write all the pages in the table. It will
detect that each page has only half the number of rows they had when they were
read into the cache in (1), and it will therefore reduce the estimate by
another 5000 rows, so that the estimate now is 0 rows, even though the table
still contains 5000 rows
> 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.
