]> Sergey Matveev's repositories - public-inbox.git/commit
extindex: support --dedupe[=MSGID]
authorEric Wong <e@80x24.org>
Sun, 25 Jul 2021 00:11:01 +0000 (00:11 +0000)
committerEric Wong <e@80x24.org>
Sun, 25 Jul 2021 00:19:19 +0000 (00:19 +0000)
commit613a1e038f9bd7b4c9287bda621b6e19eac24684
treeaa89c153ed541bc962a590b15c8f0a186e44c68e
parent3416172dbe6d05cc3272829d5448323cea3c8961
extindex: support --dedupe[=MSGID]

Sometimes I just want to dedupe a single Message-ID to test
something, and this lets me do it.

This patch appears to do what its supposed to.  But it also
appears to be finding duplicates that were previously missed.
That's a good thing, but I wish I understood what seems to be
fixed :x

I'm not sure why the previous ExtSearchIdx.pm (blob 357312b8)
was causing messages to be missed, even, and why this patch
seems to fix it...  And it's not infinite looping, either.

Anyways, before this patch, "-extindex --dedupe" was taking ~5
min to no-op every message (after the initial full --dedupe run
which took over a day to run).  No-op --dedupes now take just
under 2 hours to scan every single cross-posted message for a
no-op dedupe.  The initial dedupe took nearly 44 hours on my
system for <https://yhbt.net/lore/all/> due to SATA-2 TLC SSD
latency on 3 gigantic Xapian shards.

Running --dedupe with this change seems to prevent
/BUG\?.*?not deduplicated properly/ stderr messages from being
triggered by View.pm.  Current versions of -extindex do not
seem susceptible to introducing duplicates.
lib/PublicInbox/ExtSearchIdx.pm
script/public-inbox-extindex