Thanks for the help! I didn't know about the performance issues with byte
arrays vs numbers in this particular case.
On Mon, Nov 21, 2022 at 3:25 AM Adrien Grand wrote:
> Uwe, I think that Petko's question was about making sure that missing
> values would be returned before non-missing values, e
Uwe, I think that Petko's question was about making sure that missing
values would be returned before non-missing values, even though some of
these non-missing values might be equal to Long.MIN_VALUE. Which isn't
possible today.
I agree with your recommendation against going with bytes given the
o
Hi,
Long.MIN_VALUE and Long.MAX_VALUE are the correct way for longs to sort.
In fact if you have Long.MIN_VALUE in your collection, empty values are
treated the same, but still empty value will appear at the wanted place.
In contrast to the default "0", it is not somewhere in the middle.
Beca
Thanks Adrien, this way of doing it makes sense! I suppose another option
might be storing numbers in their byte array representations (maybe using
https://lucene.apache.org/core/9_2_0/core/org/apache/lucene/util/NumericUtils.html#longToSortableBytes(long,byte%5B%5D,int)
) in SortedDocValues and th
Hi Petko,
Lucene's comparators for numerics have this limitation indeed. We haven't
got many questions around that in the past, which I would guess is due to
the fact that most numeric fields do not use the entire long range,
specifically Long.MIN_VALUE and Long.MAX_VALUE, so using either of these
