Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1799584659.1206721464280.JavaMail.jira@brutus>
Date: Fri, 28 Mar 2008 09:24:24 -0700 (PDT)
From: "Christopher Saunders (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-909) Improve performance of String
 literals in statements
In-Reply-To: <1153814478.1138819224627.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583083#action_12583083 ] 

Christopher Saunders commented on DERBY-909:
--------------------------------------------

I am interested as taking this as a project for the Summer of Code.  Would this be a good project on its own, or should I bundle this together with re-writing test cases or fixing bugs?

> 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.