Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1749856565.1249985954811.JavaMail.jira@brutus>
Date: Tue, 11 Aug 2009 03:19:14 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-4346) LIKE with parameter recomputes
 greaterEqualString and lessThanString way too often
In-Reply-To: <2005913158.1249985834828.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-4346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-4346:
--------------------------------------

    Description: 
I profiled a 7-way join (the exact query can be found here: http://src.opensolaris.org/source/xref/opengrok/trunk/src/org/opensolaris/opengrok/history/JDBCHistoryCache_queries.properties?r=809%3Abdef8b63f333#82 ) and saw that 40% of the time was spent in Like.greaterEqualStringFromParameterWithEsc() and Like.lessThanStringFromParameterWithEsc().

These methods are used to generate "x >= greaterEqualString" and "x < lessThanString" clauses that enable a "LIKE ?" clause to make use of indexes. Since the value of the ? parameter is constant throughout a single execution of the statement, it should only be necessary to invoke these methods once per LIKE clause per execution. They are clearly called more frequently for the query in question, and reducing the number of invocations to one per execution would probably make the query execute almost twice as fast.

  was:
I profiled a 7-way join (the exact query can be found here: http://src.opensolaris.org/source/xref/opengrok/trunk/src/org/opensolaris/opengrok/history/JDBCHistoryCache_queries.properties?r=809%3Abdef8b63f333#82) and saw that 40% of the time was spent in Like.greaterEqualStringFromParameterWithEsc() and Like.lessThanStringFromParameterWithEsc().

These methods are used to generate "x >= greaterEqualString" and "x < lessThanString" clauses that enable a "LIKE ?" clause to make use of indexes. Since the value of the ? parameter is constant throughout a single execution of the statement, it should only be necessary to invoke these methods once per LIKE clause per execution. They are clearly called more frequently for the query in question, and reducing the number of invocations to one per execution would probably make the query execute almost twice as fast.


Another attempt to make the URL clickable...

> LIKE with parameter recomputes greaterEqualString and lessThanString way too often
> ----------------------------------------------------------------------------------
>
>                 Key: DERBY-4346
>                 URL: https://issues.apache.org/jira/browse/DERBY-4346
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.5.1.1
>            Reporter: Knut Anders Hatlen
>
> I profiled a 7-way join (the exact query can be found here: http://src.opensolaris.org/source/xref/opengrok/trunk/src/org/opensolaris/opengrok/history/JDBCHistoryCache_queries.properties?r=809%3Abdef8b63f333#82 ) and saw that 40% of the time was spent in Like.greaterEqualStringFromParameterWithEsc() and Like.lessThanStringFromParameterWithEsc().
> These methods are used to generate "x >= greaterEqualString" and "x < lessThanString" clauses that enable a "LIKE ?" clause to make use of indexes. Since the value of the ? parameter is constant throughout a single execution of the statement, it should only be necessary to invoke these methods once per LIKE clause per execution. They are clearly called more frequently for the query in question, and reducing the number of invocations to one per execution would probably make the query execute almost twice as fast.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.