we don't have to sort on that field
So that we thought of that approach
Thanks for your opinion
will consider improving precision step
Kind regards,
Aravinth
On Thu, Apr 6, 2017 at 8:51 PM, Erick Erickson
wrote:
> bq: What are your opinions on this?
>
> That this is not a sound approach. Why
See "termfreq" in the function query section of the reference guide.
Best,
Erick
On Thu, Apr 6, 2017 at 1:02 AM, Manjula Wijewickrema
wrote:
> Hi,
>
> I have a document collection with hundreds of documents. I need to do know
> the term frequency for a given query term in each document. I know t
bq: What are your opinions on this?
That this is not a sound approach. Why do you think Trie is expensive?
What evidence do you have at all for that? Strings are significantly
expensive relative to numeric fields. Plus, you can adjust the
precision step to reduce the "overhead" of a trie field.
I
Hi All,
I too would like to have doc'ids that are larger than int32. Not today
but in 4 years that would be very nice ;) Already we are splitting some
indexes that would be nicer together (mostly allowing more lucene code
to be used instead of our own)
On the other hand we are not the defaul
Hi all,
I'm searching numeric value and will not perform range query on that field
I thought of indexing it as String field instead of NumericField
so that it will improve indexing time by avoiding numeric tries
What are your opinions on this?
Kind regards,
Aravinth
Hi,
I have a document collection with hundreds of documents. I need to do know
the term frequency for a given query term in each document. I know that
'hit.score' will give me the Lucene score for each document (and it
includes term frequency as well). But I need to call only term frequencies
in e
