[
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 think.
I tried to change
if (oneRowResultSetForSomeConglom && costEstimate.rowCount() <= 1)
to
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 tests
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-6011
> URL: https://issues.apache.org/jira/browse/DERBY-6011
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.7.1.1, 10.8.2.2, 10.9.1.0
> 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
