From: Eric Wong <e@80x24.org>
To: meta@public-inbox.org
Subject: [PATCH 01/20] doc: rename our Xapian "partitions" to "shards"
Date: Sat, 15 Jun 2019 08:46:57 +0000 [thread overview]
Message-ID: <20190615084716.3075-2-e@80x24.org> (raw)
In-Reply-To: <20190615084716.3075-1-e@80x24.org>
For consistency with Xapian documentation (in the "master"
branch).
---
Documentation/public-inbox-v2-format.pod | 10 +++++-----
Documentation/public-inbox-xcpdb.pod | 11 +++++------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/Documentation/public-inbox-v2-format.pod b/Documentation/public-inbox-v2-format.pod
index bdfe7ab..28d3550 100644
--- a/Documentation/public-inbox-v2-format.pod
+++ b/Documentation/public-inbox-v2-format.pod
@@ -16,7 +16,7 @@ Message-IDs.
The key change in v2 is the inbox is no longer a bare git
repository, but a directory with two or more git repositories.
v2 divides git repositories by time "epochs" and Xapian
-databases for parallelism by "partitions".
+databases for parallelism by "shards".
=head2 INBOX OVERVIEW AND DEFINITIONS
@@ -28,7 +28,7 @@ foo/ # assuming "foo" is the name of the list
- inbox.lock # lock file (flock) to protect global state
- git/$EPOCH.git # normal git repositories
- all.git # empty git repo, alternates to git/$EPOCH.git
-- xap$SCHEMA_VERSION/$PART # per-partition Xapian DB
+- xap$SCHEMA_VERSION/$SHARD # per-shard Xapian DB
- xap$SCHEMA_VERSION/over.sqlite3 # OVER-view DB for NNTP and threading
- msgmap.sqlite3 # same the v1 msgmap
@@ -95,16 +95,16 @@ are documented at:
L<https://public-inbox.org/meta/20180209205140.GA11047@dcvr/>
-=head2 XAPIAN PARTITIONS
+=head2 XAPIAN SHARDS
Another second scalability problem in v1 was the inability to
utilize multiple CPU cores for Xapian indexing. This is
-addressed by using partitions in Xapian to perform import
+addressed by using shards in Xapian to perform import
indexing in parallel.
As with git alternates, Xapian natively supports a read-only
interface which transparently abstracts away the knowledge of
-multiple partitions. This allows us to simplify our read-only
+multiple shards. This allows us to simplify our read-only
code paths.
The performance of the storage device is now the bottleneck on
diff --git a/Documentation/public-inbox-xcpdb.pod b/Documentation/public-inbox-xcpdb.pod
index fd8770a..a13c4ef 100644
--- a/Documentation/public-inbox-xcpdb.pod
+++ b/Documentation/public-inbox-xcpdb.pod
@@ -21,7 +21,7 @@ L<public-inbox-watch(1)> or L<public-inbox-mda(1)>.
=item --compact
In addition to performing the copy operation, run L<xapian-compact(1)>
-on each Xapian partition after copying but before finalizing it.
+on each Xapian shard after copying but before finalizing it.
Compared to the cost of copying a Xapian database, compacting a
Xapian database takes only around 5% of the time required to copy.
@@ -32,14 +32,13 @@ the compaction to take hours at-a-time.
=item --reshard=N / -R N
-Repartition the Xapian database on a L<v2|public-inbox-v2-format(5)>
-inbox to C<N> partitions. Since L<xapian-compact(1)> is not suitable
-for merging, users can rely on this switch to repartition the
+Reshard the Xapian database on a L<v2|public-inbox-v2-format(5)>
+inbox to C<N> shards . Since L<xapian-compact(1)> is not suitable
+for merging, users can rely on this switch to reshard the
existing Xapian database(s) to any positive value of C<N>.
This is useful in case the Xapian DB was created with too few or
-too many partitions given the capabilities of the current
-hardware.
+too many shards given the capabilities of the current hardware.
=item --blocksize / --no-full / --fuller
--
EW
next prev parent reply other threads:[~2019-06-15 8:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-15 8:46 [PATCH 00/20] v2: use consistent terminology Eric Wong
2019-06-15 8:46 ` Eric Wong [this message]
2019-06-15 8:46 ` [PATCH 02/20] v2writable: update comments regarding xcpdb --reshard Eric Wong
2019-06-15 8:46 ` [PATCH 03/20] admin|xapcmd: user-facing messages say "shard" Eric Wong
2019-06-15 8:47 ` [PATCH 04/20] rename reference to git epochs as "partitions" Eric Wong
2019-06-15 8:47 ` [PATCH 05/20] searchidxpart: start using "shard" in user-visible places Eric Wong
2019-06-15 8:47 ` [PATCH 06/20] v2writable: count_partitions => count_shards Eric Wong
2019-06-15 8:47 ` [PATCH 07/20] v2writable: rename {partitions} field to {shards} Eric Wong
2019-06-15 8:47 ` [PATCH 08/20] tests: change messages to use "shard" instead of partition Eric Wong
2019-06-15 8:47 ` [PATCH 09/20] inboxwritable: s/partitions/shards/ in local var Eric Wong
2019-06-15 8:47 ` [PATCH 10/20] v2: rename SearchIdxPart => SearchIdxShard Eric Wong
2019-06-15 8:47 ` [PATCH 11/20] xapcmd: update comments referencing "partitions" Eric Wong
2019-06-15 8:47 ` [PATCH 12/20] search*: rename {partition} => {shard} Eric Wong
2019-06-15 8:47 ` [PATCH 13/20] v2writable: avoid "part" in internal subs and fields Eric Wong
2019-06-15 8:47 ` [PATCH 14/20] v2writable: rename local vars to match Xapian terminology Eric Wong
2019-06-15 8:47 ` [PATCH 15/20] adminedit: "part" => "shard" for local variables Eric Wong
2019-06-15 8:47 ` [PATCH 16/20] v2writable: use "epoch" consistently when referring to git repos Eric Wong
2019-06-15 8:47 ` [PATCH 17/20] search: use "shard" for local variable Eric Wong
2019-06-15 8:47 ` [PATCH 18/20] xapcmd: favor 'shard' over 'part' in local variables Eric Wong
2019-06-15 8:47 ` [PATCH 19/20] t/xcpdb-reshard: use 'shard' term " Eric Wong
2019-06-15 8:47 ` [PATCH 20/20] comments: replace "partition" with "shard" Eric Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://public-inbox.org/README
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190615084716.3075-2-e@80x24.org \
--to=e@80x24.org \
--cc=meta@public-inbox.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/public-inbox.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).