[
https://issues.apache.org/jira/browse/SOLR-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555450#action_12555450
]
Hoss Man commented on SOLR-440:
-------------------------------
>From an email reply i'm just now looking at...
{noformat}
Date: Sat, 22 Dec 2007 22:59:29 -0500 (EST)
From: Stu Hood
If sorting was working, why couldn't range queries be supported?
{noformat}
RangeQueries (or RangeFilters more specifically) require that a single in order
walk of the TermEnum from "low" to "high" include all values in the index that
are truly inclusive, and none that aren't .... Sorting works differently, the
first time a field is sorted on, all the values are walked and an
"inverted-invertedindex" (as i like to call it) FieldCache is built mapping
docIds to values.
Although .... assuming the FieldCache support for Longs supports a "LongParser"
the same way the Int and Float support does (i just checked, and it does) then
a "new SortableLongDateField" could be created which uses the same tricks as
SortableLongField to "index" values that sort lexigraphicaly and builds a
FieldCache using a long[] ... but knows how to parse/return ISO formated dates
(and do DateMath).
> Should use longs for internal DateField storage
> -----------------------------------------------
>
> Key: SOLR-440
> URL: https://issues.apache.org/jira/browse/SOLR-440
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 1.2, 1.3
> Reporter: Stu Hood
>
> The current DateField implementation uses formatted Strings internally to
> store dates.
> As a user creating a schema, I assumed that using the DateField type would be
> more efficient than using an integer field to store seconds. In fact, the
> DateField type is currently significantly less efficient: ~20 extra bytes are
> required per value, and String sorting requires that all values fit in memory.
> As soon as sorting on long fields has been implemented (SOLR-324), I'd
> suggest that the date implementation be switched to use long values
> internally, representing milliseconds since the epoch in UTC. Unfortunately,
> this will cause index incompatibilities, so the schema version will need to
> be bumped.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
