This is correct.
Le mer. 10 août 2016 à 14:44, Cristian Lorenzetto <
cristian.lorenze...@gmail.com> a écrit :
> I need a clarification for building a Query
> Correct me if i m wrong.
>
> for searching a number i use int/longPoint.
> for ordering the results i use docvalue field
> for retrieving t
I need a clarification for building a Query
Correct me if i m wrong.
for searching a number i use int/longPoint.
for ordering the results i use docvalue field
for retrieving the value stored i use StoredField
so if i want index,order and store a integer i need to add at least 3 fields
1 intpoint
1
thanks for suggestion about postings (i think you mean "posting format" ,
just found mentions in google now :)) I have difficulty anyway to find a
example how to use postings. Any example how to use postings in code ? just
a link for example?
*Passing to docvalues* :
in version 6.1 docvalues (like
I'm not awaken enough to figure out whether the -1 trick is right or not,
but if you manage to prove it somehow, patches to simplify boolean queries
at rewrite time are welcome!
Le mar. 9 août 2016 à 00:47, Spyros Kapnissis a
écrit :
> Hm, I hadn't really thought about the minShouldMatch part, I
It would make little sense to use points for a boolean field in the 1D case
since there are only two possible values, postings would likely be faster
and use less disk space thanks to their skipping capabilities and better
doc ID compression. Even with multiple dimensions, postings might still be
a
You shouldn't need to use setNumericPrecisionStep at all: that's how
Lucene's old numerics worked.
For boolean type, Lucene will still use one byte per value when you index
it as points (or as a term) ... I don't know how to get that down to only 1
bit :)
Mike McCandless
http://blog.mikemccandle
On Tue, Aug 9, 2016 at 7:14 PM, Yonik Seeley wrote:
But other than perhaps changing how long a DBQ takes to execute, it
> should be unrelated to the question of if other merges can proceed in
> parallel.
>
> A quick look at the lucene IndexWriter code says, no... Lucene DBQ
> processing cannot pr
in addition in the previous version of my code i used
TYPE.setNumericPrecisionStep for setting the precision of a number in
docvalues. Now i saw it is deprecated.
So i have a similar question also in this case: it is still possible
to use less space for (byte,boolean,short,int) types?
2016
ok thanks so i can do them.
but for boolean type? i could compress using bit. Is there pack function
for boolean arrays?
2016-08-10 11:25 GMT+02:00 Michael McCandless :
> It's partially right!
>
> E.g. IndexWriter will use less memory, and so you'll get better indexing
> throughput with a ShortP
It's partially right!
E.g. IndexWriter will use less memory, and so you'll get better indexing
throughput with a ShortPoint and BytePoint.
But index size will be the same, because Lucene's default codec does a good
job compressing these values.
Mike McCandless
http://blog.mikemccandless.com
On
sorry but I was developping a shortPoint and BytePoint for less using less
memory space. it is wrong?
2016-08-09 22:01 GMT+02:00 Michael McCandless :
> It's best to index numeric using the new dimensional points, e.g. IntPoint.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Tue, Au
There is no way to "update" a document in lucene, you always have to
remove the existing document and add the updated version with ALL its
fields. The updateDocument-method of IndexWriter exists only for
convenience (and to assure the operation is atomic), but internally it
does just that: remo
12 matches
Mail list logo
