db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2949) AssertionFailedError in testStalePlansOnLargeTable
Date Thu, 02 Dec 2010 17:53:11 GMT

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


Mime
View raw message