diff options
author | Ruben Laguna <ruben.laguna@gmail.com> | 2023-05-02 17:23:25 +0200 |
---|---|---|
committer | Nick Vatamaniuc <nickva@users.noreply.github.com> | 2023-05-02 11:50:45 -0400 |
commit | 2430728f57e51fb0b6fc41dfdc410ec80ced69b6 (patch) | |
tree | a961d6ff3aebfd967c89d528459358c478943e57 | |
parent | 3044528d53cc2f9197d7f431ae5f116032d08440 (diff) | |
download | couchdb-2430728f57e51fb0b6fc41dfdc410ec80ced69b6.tar.gz |
Clarify encoding length in performance.rst
The original text said that something that takes 16 hex digits can be represented with just 4 digits (in an hypothetical base62 encoding).
I believe that was a typo since 16 hex digits encode a 8-byte sequence that will require (8/3)*4 = 11 digits in base64 (without padding).
-rw-r--r-- | src/docs/src/maintenance/performance.rst | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/src/docs/src/maintenance/performance.rst b/src/docs/src/maintenance/performance.rst index 63d25caa6..c0290c3c0 100644 --- a/src/docs/src/maintenance/performance.rst +++ b/src/docs/src/maintenance/performance.rst @@ -248,8 +248,8 @@ go from 21GB to 4GB with 10 million documents (the raw JSON text when from Inserting with sequential (and at least sorted) ids is faster than random ids. Consequently you should consider generating ids yourself, allocating them sequentially and using an encoding scheme that consumes fewer bytes. -For example, something that takes 16 hex digits to represent can be done in -4 base 62 digits (10 numerals, 26 lower case, 26 upper case). +For example, 8 bytes will take 16 hex digits to represent, and those same +8 bytes can be encoded in only 11 digits/chars in base64url (no padding). Views ===== |