ructure is identical (if not 100% then at least 99%) which in my mind makes
it a more likely candidate for optimization of the fingerprint.
From: dev@solr.apache.org At: 05/05/25 15:57:55 UTC-4:00To: dev@solr.apache.org
Subject: Re: IndexFingerprint and Leader Election Slowness
Ah - I wasn't
y" do run this fingerprint for gigantic TLOG clouds
simply out of superstition. For reference, the fingerprinting feature was added
*before* TLOG+PULL feature so it wouldn't be terribly surprising if this were
an optimization that was still on the table.
>
> Luke
>
> From: dev@s
uot; do run this fingerprint for gigantic TLOG clouds
> simply out of superstition. For reference, the fingerprinting feature was
> added *before* TLOG+PULL feature so it wouldn't be terribly surprising if
> this were an optimization that was still on the table.
>
> Luke
>
perstition. For reference, the fingerprinting feature was added
*before* TLOG+PULL feature so it wouldn't be terribly surprising if this were
an optimization that was still on the table.
Luke
From: dev@solr.apache.org At: 05/05/25 13:27:32 UTC-4:00To: dev@solr.apache.org
Subject: Re: IndexFingerprint an
Yeah, I think there's a lot of room for optimization here.
I can't answer question (2) offhand, but my hunch is that PULL
replicas shouldn't need fingerprinting, even if TLOG replicas might.
(3) sounds really useful, but as you mention it has some edge cases
that might be tricky to handle (e.g. i
