Of cause! Almost too obvious ;-) thx alot - I'll spend some time wondering
why that didn't pop up in my mind as a solution.
On Thu, Dec 8, 2016 at 5:16 PM, Adrien Grand wrote:
> Le jeu. 8 déc. 2016 à 16:42, Hans Lund a écrit :
>
> > That would be a solution for
BinaryDocValueField strategy very
simple;-))
What are the drawbacks of having such a 'marker' docValue having no actual
value?
Hans Lund
On Thu, Dec 8, 2016 at 2:51 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> Unlike for doc values fields, Lucene does not st
binaryDocValueField
with empty ByteRefs for all IndexableField having DocValueType ==
DocValueTypes.NONE.
It works but is not a pretty solution, but is there any alternatives?
/Hans Lund
ommit keeping a number of snapshots
but honoring a max retention period, not that I suspect it to be the cause
- but if fieldinfos from another snapshot is used in the merge that could
cause problems
Hans Lund
On Tue, Oct 11, 2016 at 12:07 PM, Michael McCandless <
luc...@mikemccandless.com>
dIndexes?
> - customizing merging in some way, eg. by wrapping the merge readers?
>
> Le mar. 4 oct. 2016 à 16:40, Hans Lund a écrit :
>
> > After upgrading to 6.2 we are having problems during merges (after
> running
> > for a while).
> >
&
exOptions=DOCS
So any hints as to why field.fieldType().pointDimensionCount() != 0
and any suggestions what might cause this?
Regards
Hans Lund
what you expect to be
the bottleneck?
Regards
Hans Lund
On Tue, Jun 14, 2016 at 12:31 PM, Mukul Ranjan wrote:
> Hi,
>
> I have 150k documents in lucene index folder. It is taking 30-35 minute
> to rebuild the index. We are fetching this data from sql server.
> I have applied be
slow)
Any thoughts on what when its ok to call FieldCache.DEFAULT.getTerms? - Or
is this not really in any use anymore?
Regards Hans Lund
I've created https://issues.apache.org/jira/browse/LUCENE-5461, and
attached a small test that shows the error it a setup similar to what I
would like to run
The 1% is a overestimation - it seems to be related to concurrent commit on
the index writer
Hans Lund
On Thu, Feb 20, 2014 at 2:
ific
> generation.
>
> This approach is only effective if most searches can just use the
> current searcher, i.e. most searches do not need a specific
> generation. If you truly need "real-time" values for nearly all
> searches then LiveFieldValues might be useful.
&g
Hi all
I'm a bit unsure about the intended function of
the ControlledRealTimeReopenThread in a NRT context - especially regarding
stale times.
As of now if you are waiting for a generation to become refreshed, it looks
like the stale time is either the min stale time or the max stale time. Is
thi
ually reset.
Is this intentional behavior? and if so why?
Regards
Hans Lund
Hi All
I'm in the process to upgrade from 2.0 to 2.1, but are missing the
similar contrib (the jar only contains a Manifest). is this a bug or
is that on purpose?
Cheers
Hans Lund
-
To unsubscribe, e-mail: [EMAIL PROT
13 matches
Mail list logo
