> On Jul 22, 2020, at 08:52, raj.yadav wrote:
>
> Erik Hatcher-4 wrote
>> Wouldn’t a “string” field be as good, if not better, for this use case?
>
> What is the rationale behind this type change to 'string'. How will it speed
> up search/filtering? Will it not increase the index size. Since
pints
1> take up less space (IIRC)
2> are better for range queries.
Best,
Erick
> On Jul 22, 2020, at 8:49 AM, raj.yadav wrote:
>
> Erik Hatcher-4 wrote
>> Wouldn’t a “string” field be as good, if not better, for this use case?
>
> What is the rationale behind this type change to 'string'. Ho
Erik Hatcher-4 wrote
> Wouldn’t a “string” field be as good, if not better, for this use case?
What is the rationale behind this type change to 'string'. How will it speed
up search/filtering? Will it not increase the index size. Since in general
string type takes more space storage then int (not
Erick Erickson wrote
> Also, the default pint type is not as efficient for single-value searches
> like this, the trie fields are better. Trie support will be kept until
> there’s a good alternative for the single-value lookup with pint.
>
> So for what you’re doing, I’d change to TrieInt, docValu
Wouldn’t a “string” field be as good, if not better, for this use case?
> On Jul 22, 2020, at 08:02, Erick Erickson wrote:
>
> fq clauses are just like the q clause except for two things:
> 1> no scoring is done
> 2> the entire result set _can_ be stored in the filterCache.
>
> so if a value i
fq clauses are just like the q clause except for two things:
1> no scoring is done
2> the entire result set _can_ be stored in the filterCache.
so if a value isn’t indexed, it can’t be used in either an fq or q clause.
The thread you reference is under the assumption (and this is the default in
