[
https://issues.apache.org/jira/browse/DERBY-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583094#action_12583094
]
Bryan Pendleton commented on DERBY-909:
---------------------------------------
Hi Christopher, thanks for getting involved in Derby! I think this work would
be well suited for the Summer of Code time frame. Here's a couple other
thoughts:
- as part of working on this project, there will be a fair amount of test work;
you'll want to be writing new tests, and possibly revising and improving
existing tests. So being familiar with the overall test harness will be
important, and converting existing tests to JUnit and fixing existing bugs
are both good ways to become familiar with the overall test harness.
- I think that until you've investigated this project in more detail, it won't
be easy to tell whether, by itself, it is "meaty" enough to occupy you for
the entire duration of the SoC program. My hunch is that it's probably too
small a project on it's own, although as you can see there is room to
expand it; note Dan's comment "It would also be a step on the way to
having a single compiled plan for such statements that don't use
parameter markers."
So I guess I'm suggesting that bundling it with some test case re-writing,
hopefully of existing test cases that are directly relevant to this feature,
seems
like a good idea to me.
> 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: Newcomer, 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.
