lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom Hill (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-1508) Use field cache when creating response, if available and configured.
Date Tue, 13 Oct 2009 22:47:31 GMT

    [ https://issues.apache.org/jira/browse/SOLR-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765288#action_12765288
] 

Tom Hill commented on SOLR-1508:
--------------------------------

Starting with the hard part makes some sense, not sure if we should continue that part here,
or in SOLR-1298.

Comments on "things to think about"

1 & 2) I think this (SOLR-1508) would work as one implementation of a mechanism to get
things other than 'normal' fields (cache, function queries). It makes sense for there to be
an overall common interface for this.

3) a) In this implementation, the user configures an alternate name for the field. (e.g. foobar_cached).
If they ask for that, they get the cached version. If they use the real name, they retrieve
as usual. b) I think it would make sense to allow the cache to be configurable to cache a
stored field or an indexed term, but I have not done this yet.

4) I can't comment on this one, as I haven't looked at uninvertedField.

5) For this use case, I think it makes sense for fl=* to get only the original document. If
you are getting any other fields, you have to go to the disk, so the advantage of the cache
will largely be lost. But I do think this also might be a reasonable default for the other
cases. That is, "Ask for it, if you want something extra"

6) I don't have an answer on this one yet. I'm working with Strings right now.

And, as for this implementation, you are right, IndexSearcher does have start information.
I'd looked for accessors, I hadn't thought to look for other places the same info was recreated.

And you could then call DirectoryReader.readerIndex(), passing in starts[]. But the implementation
of gatherSubreaders is recursive, and the implementation in DirectoryReader is not, and I'm
really not clear if that would matter. It just seems a lot more stable to have each class
do its own look offset calculations and segment look-up.

Also, If you wanted to not have the caches baked into IndexReader's api, we could make a method
that returns the relevant reader and offset and then use that to look up in the cache externally.
It's a little more general, but a little more code, so I initially went with the simpler approach.


> Use field cache when creating response, if available and configured.
> --------------------------------------------------------------------
>
>                 Key: SOLR-1508
>                 URL: https://issues.apache.org/jira/browse/SOLR-1508
>             Project: Solr
>          Issue Type: New Feature
>          Components: search
>    Affects Versions: 1.3
>            Reporter: Tom Hill
>
> Allow the user to configure a field to be returned to the user from the field cache,
instead of getting the field from disk. Relies on lucene-1981

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message