This wasn't wired up properly, but Xapian appears to suffer from
I/O amplification problems as DB shards get larger:
https://lists.xapian.org/pipermail/xapian-discuss/2019-February/009727.html
<23640.32170.703368.841021@y.dockes.com>
Of course, we shouldn't have too many shards, either; because
performance problems with too many shards was the entire reason
extindex was created:
https://lists.xapian.org/pipermail/xapian-discuss/2020-August/009823.html
<
20200826064728.GA32239@dcvr>
parallel => 1,
lock_path => "$dir/ei.lock",
}, __PACKAGE__;
- $self->{shards} = $self->count_shards || nproc_shards($opt->{creat});
+ $self->{shards} = $self->count_shards ||
+ nproc_shards({ nproc => $opt->{jobs} });
my $oidx = PublicInbox::OverIdx->new("$self->{xpfx}/over.sqlite3");
$self->{-no_fsync} = $oidx->{-no_fsync} = 1 if !$opt->{fsync};
$self->{oidx} = $oidx;
'--dry-run alone fails');
}
+for my $j (1, 3, 6) {
+ my $o = { 2 => \(my $err = '') };
+ my $d = "$home/extindex-j$j";
+ ok(run_script(['-extindex', "-j$j", '--all', $d], undef, $o),
+ "init with -j$j");
+ my $max = $j - 2;
+ $max = 0 if $max < 0;
+ my @dirs = glob("$d/ei*/?");
+ like($dirs[-1], qr!/ei[0-9]+/$max\z!, '-j works');
+}
+
done_testing;