[
https://issues.apache.org/jira/browse/SOLR-440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555663#action_12555663
]
Hoss Man commented on SOLR-440:
-------------------------------
depending on what the final implementation looks like, i could easily be
convinced to use a new class like this in the example configs, and maybe even
go so far as to deprecate the existing DateFiled ... but i can't imagine being
convinced to completley replaced DateField with it at any point ... a RAM
performance improvement in sorting doesn't seem worth breaking back
compatibility and forcing people to reindex ... not when it would be just as
easy to add a new (subclass) FieldType.
consider the people who currently use DateField for range queries but never for
sorting -- they'll be pretty upset if we tell them they have to reindex and
they won't see any noticeable benefit from doing so.
> 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.
