[
https://issues.apache.org/jira/browse/SOLR-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491013#comment-13491013
]
Robert Muir commented on SOLR-3855:
-----------------------------------
{quote}
and it would make sense to make FIXED_INTS_32 the default docValueType for
TrieIntField.
{quote}
Are you sure only one thing makes sense? What if i need integers that are
larger than a short, but the range of values (max-min)
is actually small. Then a Packed impl could make more sense. So we should think
about this...
{quote}
Additionally, maybe that not having to learn about all DocValues types before
using them would make their adoption smoother?
{quote}
Well I don't think there should be so many types :)
There is a big todo about this in DocValues.java.
In my opinion instead of IndexWriter streaming docvalues to the codec directly,
only to have the codec buffer up in ram and use
Counter for accounting, IndexWriter should buffer and things like STRAIGHT/VAR
would just be optimizations...
I guess i think the same as for ints, just like if you asked for packed and its
going to need 64 bits, its implemented as that
behind the scenes (but then still "pretends" to be a packed field, which is
wierd!).
But this is a little off-topic :)
{quote}
I like this argument (forcing the trade-off to be explicit)! But this makes me
want to merge DocValues activation with the method instead of the type. For
example we could say docValues=no|disk|memory (optional, defaults to "no",
"disk" to enable direct doc values, "memory" otherwise) docValueType=$\{type}
(optional, default value depends on the FieldType, only taken into account when
"docValues" is set and is not "no").
{quote}
I think this is good!
{quote}
I wanted them to behave like stored fields so that users don't make their
fields stored in addition to DocValues for convenience (this is a waste of
space, and the bigger the FDT file is, the more likely the I/O cache can't
serve disk seeks in this file).
{quote}
I'm still worried about this case: I don't like them treated as stored fields.
Its only going to be more seeks if people have disk-enabled dvs
that we must fetch in addition to the stored fields.
I havent looked at the relevant bits, but is it possible we could treat "*" as
just meaning the stored fields still? Basically, if you CHOOSE to
request them, you get them, but we don't do anything trappy.
> DocValues support
> -----------------
>
> Key: SOLR-3855
> URL: https://issues.apache.org/jira/browse/SOLR-3855
> Project: Solr
> Issue Type: Improvement
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-3855.patch
>
>
> It would be nice if Solr supported DocValues:
> - for ID fields (fewer disk seeks when running distributed search),
> - for sorting/faceting/function queries (faster warmup time than fieldcache),
> - better on-disk and in-memory efficiency (you can use packed impls).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
