You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Przemo Pakulski (JIRA)" <ji...@apache.org> on 2014/08/27 11:54:58 UTC
[jira] [Comment Edited] (OAK-2056) Optimize ordering by date fields
[ https://issues.apache.org/jira/browse/OAK-2056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14112094#comment-14112094 ]
Przemo Pakulski edited comment on OAK-2056 at 8/27/14 9:54 AM:
---------------------------------------------------------------
I think the reason is that comparator used to sort results have to parse date each time when a comparison is needed.
{code}
PropertyStateValue.compareAsDate(...)
{code}
And number of comparisons grows exponentially with a large size of results.
Is there any reason why dates are using GenericPropertyState which keeps internally date as string ? Can we instead create a "DatePropertyState" which keeps date as a long or Calendar?
was (Author: ppakulski):
I think the reason is that comparator used to sort results have to parse date each time when a comparison is needed.
{code}
PropertyStateValue.compareAsDate(...)
{code}
And number of comparisons grows exponentially with a large size of results.
> Optimize ordering by date fields
> --------------------------------
>
> Key: OAK-2056
> URL: https://issues.apache.org/jira/browse/OAK-2056
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
> Affects Versions: 1.0.4
> Reporter: Przemo Pakulski
>
> Sorting by date fields is very slow in oak, especially if result set size is large.
> I'm running the following JCR-SQL2 query
> {code}
> SELECT * FROM [cq:PageContent] AS [c] WHERE ISDESCENDANTNODE('/content')
> {code}
> which returns 3270 results on my oak repo.
> Query execution times are as below
> ---------------------------------------
> No order clause | 0,147 sec
> ORDER BY [jcr:createdBy] | 1,018 sec
> ORDER BY [jcr:created] | 25,229 sec
> Ordering by date field adds extra 24 seconds overhead.
--
This message was sent by Atlassian JIRA
(v6.2#6252)