In standard Lucene this information is not stored, but I wrapped the
default MergePolicy to be able to store the merged segments.
It works great, except for point-in-time merges occurring during segment
flush.
Le 16/12/2024 à 16:31, David Smiley a écrit :
Not sure if the segment metadata contains merge info on what segments it
merged. I suppose that's what you'd like. You might be able to add such
metadata; not sure.
On Mon, Dec 16, 2024 at 8:50 AM Cédric Damioli<cdami...@apache.org> wrote:
Hi David,
Le 15/12/2024 à 18:50, David Smiley a écrit :
Hi Cedric,
On Fri, Dec 13, 2024 at 6:38 PM Cédric Damioli<cdami...@apache.org>
wrote:
Is there a way to listen to such
behaviour or to have a callback called ?
On this point I'm unclear what the problem is. Why does it matter that
your listener doesn't "see" segment _2? It will see segment _3 (which
includes the data from _2 as it's the merged segment).
I have a very costly cache, computed once for each segment, and passed
along from oldSearcher to newSearcher at searcher creation time through
an event listener.
I store (in the SegmentInfo diagnostics map) the origin of a merged
segment, so that at searcher creation I know that _3 is actually a merge
from _0, _1 and _2, so that I may rebuild the new cache from the old
caches, without having to recompute it.
But in the above case, if I "miss" a segment creation, that algorithm
can't work, and I have to compute it again.
That's why I looked for a sort of callback for handling these cases.
Regards,
Cédric
