Ok, thank you...
On Thu, 4 Apr 2019, 13:08 Adrien Grand, wrote:
> Difference in performance, indexing speed and index size will greatly
> depend on the data. There is some data at
> https://www.elastic.co/blog/searching-numb3rs-in-5.0.
>
> FYI there is one known case when points perform worse th
Difference in performance, indexing speed and index size will greatly
depend on the data. There is some data at
https://www.elastic.co/blog/searching-numb3rs-in-5.0.
FYI there is one known case when points perform worse than legacy
numeric fields: exact queries on low-cardinality fields. But if yo
Hi
Thank you for your response.
Yes moving to 8.0 will be the plan if we plan to re-index.
Before we re-index would like to know few details which will help us to
decide further on that:
In Lucene 6.0 migrate page(https://lucene.apache.org/core/6_0_0/MIGRATE.html)
it says "*PointValues replaces
IndexUpgrader would not help, you need to reindex indeed using your
own Java program.
If you plan to reindex, then you might want to look into going
straight to Lucene 8.0 (latest).
On Wed, Apr 3, 2019 at 9:04 AM brahmam wrote:
>
> Hi,
>
> Thanks for your response.
>
> Does the IndexUpgrader too
Hi,
Thanks for your response.
Does the IndexUpgrader tool will help in order to re-index using LongPoint ?
Or
Do we need to create completely new Index using LongPoint by writing a java
programme ?
Or
any other tool or best way to do ?
Thank you in Advance!
On Tue, Apr 2, 2019 at 6:17 PM Adri
You got it right, you will need to reindex with LongPoint before being
about to search with LongPoint#newRangeQuery. It's fine to keep using
LegacyNumericRangeQuery until then.
On Tue, Apr 2, 2019 at 1:56 PM brahmam wrote:
>
> Hi,
>
> Thanks for your response.
>
> Now that in 6.6.5 it recommends
Hi,
Thanks for your response.
Now that in 6.6.5 it recommends to use LongPoint.newRangeQuery() instead
of deprecated LegacyNumericRangeQuery.newLongRange(),
So Does it means, we need to re-index old data using LongPoint so that it
is searchable in upgrade scenarios ?
In general Lucene supports
Hi Brahmam,
This isn't possible: data can only be searched with
LongPoint#newRangeQuery if the field has been indexed with LongPoints.
On Tue, Apr 2, 2019 at 7:04 AM brahmam wrote:
>
> Hi,
>
> In continuation to the previous mail, we see for the second point the newly
> added data after upgrade
Hi,
In continuation to the previous mail, we see for the second point the newly
added data after upgrade will not be searchable if we use
LegacyNumericRangeQuery.newLongRange(). so the second point is invalid now.
So please suggest on the point 1 how to search old and new data using
LongPoint.new
Hi,
The main idea to migrate to 6.6.5(not to 7.6.x) from 5.5.3 is to have
smooth upgrade by avoiding re-indexing of the data at this point of time.
Coming to the issue of not able to search the old data(which was indexed
with 5.5.3) when we upgrade to 6.6.5 is
> The old data search works fine if
First I have to ask why not use something much more recent? 7.5 comes to mind.
There’s not enough information here to say anything at all about what your
problem might or might not be. “It doesn’t work” provides little to diagnose.
You might want to review:
https://wiki.apache.org/solr/UsingMai
Hi Team,
we want to migrate from lucene 5.5.3 to 6.6.5.
We see after upgraded to 6.6.5 we are not able to search the existing
data(which was managed with 5.5.3), are we missing anything here during
upgrade?
--
Thanks & Regards,
Sree
12 matches
Mail list logo
