[
https://issues.apache.org/jira/browse/DERBY-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798014#action_12798014
]
Knut Anders Hatlen commented on DERBY-909:
------------------------------------------
For the record, I tried the naive approach of changing
CharConstantNode.generateConstant() to generate byte code equivalent to this
Java code:
(String) activation.getPreparedStatement().getSavedObject(idx)
It worked for some queries, and failed with a NullPointerException in others.
(For example, VALUES 'abc' failed with NPE.) The problem appeared to be that
the generated code could be executed before the activation had been initialized
properly, so that the prepared statement was null.
See also this comment in UserTypeConstantNode, describing what looks like the
same problem:
// The code generated here is invoked when the generated class is
constructed. However the prepared statement
// is not set into the activation class when it is constructed, but
later. So we cannot use the getSavedObject
// method to retrieve the value.
// else if( value instanceof DataValueDescriptor)
// {
// acb.pushThisAsActivation( mb);
// mb.callMethod( VMOpcode.INVOKEINTERFACE,
// null,
// "getPreparedStatement",
// ClassName.ExecPreparedStatement,
// 0);
// mb.push( acb.addItem( value));
// mb.callMethod( VMOpcode.INVOKEINTERFACE,
// null,
// "getSavedObject",
// "java.lang.Object",
// 1);
// mb.cast( fieldType);
// }
> Improve performance of String literals in statements
> ----------------------------------------------------
>
> Key: DERBY-909
> URL: https://issues.apache.org/jira/browse/DERBY-909
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Reporter: Daniel John Debrunner
> Priority: Minor
>
> String literals (constants) go through this process currently
> Create String object from within parser
> Serialized String into generated class file as UTF-8 (taking up two constant
> pool entries)
> Unserialize and intern String from generated class at class load time
> The serialize into the class file and un-serialize can be avoided by saving
> the String in the saved object pool (see CompilerContext)
> This would benefit the common pattern we see in SQL scripts that load data
> like:
> insert into customer values (1, 'Fred', 'Flintstone');
> insert into customer values (2, 'Wilma'', 'Flintstone');
> etc.
> etc.
> Note these are poor performing in Derby compared to other databases.
> It would also be a step on the way to having a single compiled plan for such
> statements that don't use parameter markers.
> Most likely the performance benefit with inserts will be small until
> DERBY-888 is fixed, because with inserts the sync of the allocated pages
> dominates the cost.
> Possible newcomer task with guideance.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
