[
https://issues.apache.org/jira/browse/OPENJPA-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625770#action_12625770
]
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: https://issues.apache.org/jira/browse/OPENJPA-703
> 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.
