db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-3955) test lang/selectivity.sql can be revived
Date Tue, 21 Jan 2014 21:12:21 GMT

    [ 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

> 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,
> 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

View raw message