openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ron Pressler (JIRA)" <>
Subject [jira] Commented: (OPENJPA-703) Cache ResultObjectProvider data to improve query performance
Date Tue, 26 Aug 2008 15:30:44 GMT


Ron Pressler commented on OPENJPA-703:

I was referring to caching only the parsed query, not the results (interestingly enough, the
ResultObjectProvider returned from JDBCStoreQuery.executeQuery does not, in fact, contain
any results). 
As for the fetch plan - if it indeed affects the generated SQL (as I assume it does), then
it must be part of the cache key. It does not, however, make sense that, in a very common
use-case. when I execute the same query over and over in my application (using the same fetch
plan obviously), the SQL statement needs to be generated each time by analyzing the metadata
of an entire class hierarchy. This was shown in practice to consume a lot of CPU resources.

> Cache ResultObjectProvider data to improve query performance
> ------------------------------------------------------------
>                 Key: OPENJPA-703
>                 URL:
>             Project: OpenJPA
>          Issue Type: Improvement
>          Components: kernel
>            Reporter: Ron Pressler
> Profiling indicated that JDBCStoreQuery.populateSelect consumes a significant amount
of CPU, and is executed every time a query is run. While, in fact, the actual PreparedStatement
is created and run only in QueryImpl.toResult. It seems like the returned ResultObjectProvider
from JDBCStoreQuery.executeQuery can be at least partially cached, or even cached in its entirety
(provided care is taken with the context parameters). 
> It seems like such an improvement would significantly improve query performance.

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

View raw message