user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* [PATCH 00/20] v2: use consistent terminology
@ 2019-06-15  8:46  7% Eric Wong
  2019-06-15  8:46  5% ` [PATCH 01/20] doc: rename our Xapian "partitions" to "shards" Eric Wong
  0 siblings, 1 reply; 2+ results
From: Eric Wong @ 2019-06-15  8:46 UTC (permalink / raw)
  To: meta

Modern Xapian docs and code refer to multi-DB uses as "shards";
so replace the term "partition" with the term "shard".  This
way, we'll minimize the learning curve for people new to
public-inbox or Xapian.

We also still had a few places where we referred to git epochs
as "partitions", so fix those up and be consistent with the
majority of our own docs and code.

Eric Wong (20):
  doc: rename our Xapian "partitions" to "shards"
  v2writable: update comments regarding xcpdb --reshard
  admin|xapcmd: user-facing messages say "shard"
  rename reference to git epochs as "partitions"
  searchidxpart: start using "shard" in user-visible places
  v2writable: count_partitions => count_shards
  v2writable: rename {partitions} field to {shards}
  tests: change messages to use "shard" instead of partition
  inboxwritable: s/partitions/shards/ in local var
  v2: rename SearchIdxPart => SearchIdxShard
  xapcmd: update comments referencing "partitions"
  search*: rename {partition} => {shard}
  v2writable: avoid "part" in internal subs and fields
  v2writable: rename local vars to match Xapian terminology
  adminedit: "part" => "shard" for local variables
  v2writable: use "epoch" consistently when referring to git repos
  search: use "shard" for local variable
  xapcmd: favor 'shard' over 'part' in local variables
  t/xcpdb-reshard: use 'shard' term in local variables
  comments: replace "partition" with "shard"

 Documentation/public-inbox-v2-format.pod      |  10 +-
 Documentation/public-inbox-xcpdb.pod          |  11 +-
 MANIFEST                                      |   2 +-
 lib/PublicInbox/Admin.pm                      |   4 +-
 lib/PublicInbox/AdminEdit.pm                  |  12 +-
 lib/PublicInbox/Inbox.pm                      |  18 +--
 lib/PublicInbox/InboxWritable.pm              |   4 +-
 lib/PublicInbox/Search.pm                     |  14 +--
 lib/PublicInbox/SearchIdx.pm                  |  19 +--
 .../{SearchIdxPart.pm => SearchIdxShard.pm}   |  30 ++---
 lib/PublicInbox/V2Writable.pm                 | 109 +++++++++---------
 lib/PublicInbox/WWW.pm                        |  12 +-
 lib/PublicInbox/WwwListing.pm                 |   2 +-
 lib/PublicInbox/WwwStream.pm                  |  12 +-
 lib/PublicInbox/Xapcmd.pm                     |  96 +++++++--------
 t/indexlevels-mirror.t                        |   2 +-
 t/psgi_v2.t                                   |   2 +-
 t/v2writable.t                                |   4 +-
 t/view.t                                      |   2 +-
 t/xcpdb-reshard.t                             |  14 +--
 20 files changed, 188 insertions(+), 191 deletions(-)
 rename lib/PublicInbox/{SearchIdxPart.pm => SearchIdxShard.pm} (78%)

-- 
EW


^ permalink raw reply	[relevance 7%]

* [PATCH 01/20] doc: rename our Xapian "partitions" to "shards"
  2019-06-15  8:46  7% [PATCH 00/20] v2: use consistent terminology Eric Wong
@ 2019-06-15  8:46  5% ` Eric Wong
  0 siblings, 0 replies; 2+ results
From: Eric Wong @ 2019-06-15  8:46 UTC (permalink / raw)
  To: meta

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


^ permalink raw reply related	[relevance 5%]

Results 1-2 of 2 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2019-06-15  8:46  7% [PATCH 00/20] v2: use consistent terminology Eric Wong
2019-06-15  8:46  5% ` [PATCH 01/20] doc: rename our Xapian "partitions" to "shards" Eric Wong

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).