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-6011) Derby performs very badly (seems to deadlock and timeout) in very simple multi-threaded tests
Date Tue, 15 Jan 2013 12:46:13 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13553741#comment-13553741

Knut Anders Hatlen commented on DERBY-6011:

The code I mentioned in FromBaseTable.estimateCost() does not come into play here because
it is only used if the row count of the non-unique index is <= 1. In this query, the estimated
row count is 6 (because the 10% selectivity of the predicate hasn't been applied yet).

Since we know at this point that there is a unique index, and that we have equality predicates
for each column in the key, we also know that the unique index is guaranteed to return at
most one row. So do we really need to check if the row count of the non-unique index is <=
1 to determine that it's reasonable to favor the unique index? The more rows we expect from
the non-unique index, the more likely it is that the unique index is a better choice, I would

I tried to change
    if (oneRowResultSetForSomeConglom && costEstimate.rowCount() <= 1)
    if (oneRowResultSetForSomeConglom && costEstimate.rowCount() <= 10)
or just
    if (oneRowResultSetForSomeConglom)

Both of the alternatives made the test pick the unique index, and the deadlocks on the jobqueue
table went away.
> Derby performs very badly (seems to deadlock and timeout) in very simple multi-threaded
> ---------------------------------------------------------------------------------------------
>                 Key: DERBY-6011
>                 URL: https://issues.apache.org/jira/browse/DERBY-6011
>             Project: Derby
>          Issue Type: Bug
>    Affects Versions:,,
>         Environment: Lenovo laptop with SSD's, Windows 7, 64-bit, Sun JDK 1.6.xx
>            Reporter: Karl Wright
>         Attachments: derby.log, force-specific-index.diff, manifoldcf.log
> The Apache ManifoldCF project supports Derby as one of its underlying databases.  Simple
tests, however, demonstrate that Derby is apparently deadlocking and timing out repeatedly
under multi-thread conditions.  This problem is long-standing, and is not exhibited by any
other database ManifoldCF supports, and makes a simple test take between 6x and 12x as long.
> There is a trivial test with demonstrates the problem vs. other databases.  Please do
the following (once you have java 1.6+, svn 1.7+, and ant 1.7+ available):
> (1) Check out https://svn.apache.org/repos/asf/manifoldcf/trunk
> (2) Run the following ant target to download the dependencies: "ant make-core-deps"
> (3) Run the Derby test: "ant run-rss-tests-derby" . Note the time required - at least
180 seconds, can be up to 360 seconds.
> (4) Run the equivalent HSQLDB test: "ant run-rss-tests-HSQLDB".  This test takes about
31 seconds to run.
> The output of the Derby test can be found in the directory "tests/rss/test-derby-output".
 Have a look at manifoldcf.log, where all long-running queries are reported.  Derby.log is
also included, which shows only that during the test's cleanup phase the database is deleted
before it is shutdown, which is not pertinent to the performance issue.
> I am available to assist with ManifoldCF, if that seems to be required.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message