[
https://issues.apache.org/jira/browse/DERBY-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16444259#comment-16444259
]
martin stanik commented on DERBY-1996:
--------------------------------------
Problem is in condition part of query, which executes derby during
DatabaseMetadata.getColumns().
The condition has part: AND (S.SCHEMANAME LIKE ?) AND (T.TABLENAME LIKE ?) AND
(C.COLUMNNAME LIKE ?)
User often specifies only schema, with table and column pattern '%'.
As explained by Tunning Derby, part LIKE transformations, derby chooses bad
plan for patterns starting with '%'.
Passing double '%' reliably kills Your chances to get a quick response.
> DatabaseMetaData.getColumns() takes long time to return columns for a
> particular schema of Apache JDO TCK
> ---------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1996
> URL: https://issues.apache.org/jira/browse/DERBY-1996
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.2.1.6
> Reporter: Andy Jefferson
> Priority: Major
> Labels: derby_triage10_11
> Attachments: testcase.zip
>
>
> When running the Apache JDO "TCK", JPOX needs to query the columns for a
> particular schema, and so uses DatabaseMetaData.getColumns(null, schemaName,
> null, null). This takes the order of 3 minutes on a dual-core Pentium 3GHz
> (with large ram). I've cut the JPOX part down to a stand-alone test (will
> attach it).
> Thing to note is that with only the schema files d_* installed it takes the
> order of 20secs. When the schema_* files are also installed then performance
> goes downhill fast (even though they are in different schemas ... all *.sql
> file represents a different schema). No point in me postulating what could be
> the issue since you guys are the Derby experts.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
