[
https://issues.apache.org/jira/browse/DERBY-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-3955:
----------------------------------
I am not sure what is going on here, but thought I would bring up the store
part of this equation -- which might make
sense of your test cases.
Store maintains an "estimated" row count of a table, it does not guarantee that
it matches the exact count of
rows in the table and often it does not. This count is updated either when the
store thinks the number has been
changed by 10% or when a dirty page leaves the cache. So the number can vary
depending on what state the cache
is in before the test is run.
Note the counts I am talking about are the raw counts on the individual tables,
where the counts you are looking at
come from doing additional math on those numbers - that math is in the
optimizer.
There are some points in the code where the sql layer of the system "knows"
that it has just done a scan of every
row in the table so it knows the exact count of the table and it updates the
store's estimate through a store interface.
I think this is triggered by a full index or base table scan. But would be
reasonable to do a create index and update
statistic time also.
I also believe creating an index after data is added to the table does the same
thing as what update statistics does, if
there is only one index on the table. The cardinality statistics are only
gathered on existing indexes.
> test lang/selectivity.sql can be revived
> ----------------------------------------
>
> Key: DERBY-3955
> URL: https://issues.apache.org/jira/browse/DERBY-3955
> Project: Derby
> Issue Type: Test
> Components: Test
> Reporter: Myrna van Lunteren
> Assignee: Kathey Marsden
> Priority: Minor
> Attachments: DERBY-3955.diff1,
> derby-3955_sanityCheck_dont_commit_diff.txt, oldSelectivity.java
>
>
> One test that was contributed during the IBM contribution of derby code was
> not runnable at the time - lang/selectivity.sql.
> This test is still there, and I think might have some valuable regression
> tests if it gets adapted to the current functionality in Derby.
> Ideally too, it should get converted to junit, or at least be made to run
> through the langScripts junit suite.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
