You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "martin stanik (JIRA)" <ji...@apache.org> on 2018/04/19 15:34:00 UTC
[jira] [Commented] (DERBY-1996) DatabaseMetaData.getColumns() takes
long time to return columns for a particular schema of Apache JDO TCK
[ 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)