[
https://issues.apache.org/jira/browse/DERBY-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13877859#comment-13877859
]
Mike Matrigali commented on DERBY-3955:
---------------------------------------
In general I think checking for specific estimated row counts is a bad idea in
tests, unless there is a very specific need to do so. Tests that look at plans
should be looking at the shape of the plan, and the specific estimates do not
matter. Check that the expected statement nodes using the expected indexes are
there.
In some cases estimates are going to be affected by background activity and
may thus lead to intermittent failures when run across hardware.
If you must check for specific estimates do everything you can to isolate your
test from varying performance issues:
o turn off the automatic background statistics gatherer (as you can't be sure
when it will kick in across platforms and thus estimates might be affected by
machines).
o run the test in a different db than other tests. the row estimates in store
are just estimates, and they are updated internally based on page cache events
(like a page with deleted or inserted rows getting written to disk). The state
of the cache may be dependent on previous tests. It may be ok to just shutdown
and restart before the test, but certainly running in a different db is safest.
o after you change the number of rows in a table run an compress on the tables.
again estimates are based on cache behavior, and especially after deletes
there are background jobs going on recovering the deleted space and they may
perform differently on different machines. running a compress after update,
delete, and or inserts will get the row estimates from store into a
reproducible state. some of the code uses an internal procedure to wait for
background tasks to finish, but my opinion is that we should use "supported"
interfaces in tests whenever possible. If the test needs to specifically
exercise the path where there are committed deleted rows in the table that have
not been reclaimed it may then be necessary to use the internal call to get
reproducible results. Probably most query plan tests can follow a mode where
they do all the ddl and data load up front and run compress to get system to
known estimate state.
> test lang/selectivity.sql can be revived
> ----------------------------------------
>
> Key: DERBY-3955
> URL: https://issues.apache.org/jira/browse/DERBY-3955
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Reporter: Myrna van Lunteren
> Priority: Minor
> Attachments: DERBY-3955.diff1, DERBY-3955.diff2,
> 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 was sent by Atlassian JIRA
(v6.1.5#6160)
