Hi, +1 to "speeding up the ordered index" (as the subject says)
But: -1 to _not_ sorting accurately up to the millisecond, when using "order by". See also my comment on OAK-2028. I consider it a bug if somebody runs a query with "order by lastModified" and then the result is ordered by a truncated version of "lastModified" (depending on the index configuration). Regards, Thomas On 07/08/14 11:22, "Davide Giannella" <[email protected]> wrote: >Hello team, > >I was thinking in background around how we could speed-up the current >ordered index and just realised the our main use case is the indexing of >dates. > >Currently the index indexes the full date translated into a string[0] up >to the 'Z' of the JCR date format[1] > >(0) http://goo.gl/e3Gr9V >(1) http://goo.gl/VOtjfi > >This will produce tons of keys in the index. I would say one for each >node. If we truncate the date up to the minute or the second we could >reduce drastically this aspect. > >The query engine is anyhow double-checking the conditions when fetching >the results. > >My main concern now is understanding what it would be a proper truncate >line. > >Truncating to the second could give us a bucket of 1k elements plus >time-zones. > >Truncating to the minute could give us 60k buckets plus time-zones. > >Thoughts? Am I missing anything here? > >thank you >Davide > >
