Merge branch 'mongodb-3.4' into mongodb-3.2mongodb-3.2.13

16 files changed, 516 insertions, 235 deletions

diff --git a/src/docs/Doxyfile b/src/docs/Doxyfile
index 69e9716b425..3d8c46962f1 100644
--- a/src/docs/Doxyfile
+++ b/src/docs/Doxyfile
@@ -216,11 +216,19 @@ ALIASES                = "notyet{1}=Note: <b>"\1"</b> not yet supported in Wired
                          "hrow{3}=<tr><th>\1</th><th>\2</th><th>\3</th></tr>" \
                          "hrow{4}=<tr><th>\1</th><th>\2</th><th>\3</th><th>\4</th></tr>" \
                          "hrow{5}=<tr><th>\1</th><th>\2</th><th>\3</th><th>\4</th><th>\5</th></tr>" \
+                         "hrow{6}=<tr><th>\1</th><th>\2</th><th>\3</th><th>\4</th><th>\5</th><th>\6</th></tr>" \
+                         "hrow{7}=<tr><th>\1</th><th>\2</th><th>\3</th><th>\4</th><th>\5</th><th>\6</th><th>\7</th></tr>" \
+                         "hrow{8}=<tr><th>\1</th><th>\2</th><th>\3</th><th>\4</th><th>\5</th><th>\6</th><th>\7</th><th>\8</th></tr>" \
+                         "hrow{9}=<tr><th>\1</th><th>\2</th><th>\3</th><th>\4</th><th>\5</th><th>\6</th><th>\7</th><th>\8</th><th>\9</th></tr>" \
                          "row{1}=<tr><td>\1</td></tr>" \
                          "row{2}=<tr><td>\1</td><td>\2</td></tr>" \
                          "row{3}=<tr><td>\1</td><td>\2</td><td>\3</td></tr>" \
                          "row{4}=<tr><td>\1</td><td>\2</td><td>\3</td><td>\4</td></tr>" \
                          "row{5}=<tr><td>\1</td><td>\2</td><td>\3</td><td>\4</td><td>\5</td></tr>" \
+                         "row{6}=<tr><td>\1</td><td>\2</td><td>\3</td><td>\4</td><td>\5</td><td>\6</td></tr>" \
+                         "row{7}=<tr><td>\1</td><td>\2</td><td>\3</td><td>\4</td><td>\5</td><td>\6</td><td>\7</td></tr>" \
+                         "row{8}=<tr><td>\1</td><td>\2</td><td>\3</td><td>\4</td><td>\5</td><td>\6</td><td>\7</td><td>\8</td></tr>" \
+                         "row{9}=<tr><td>\1</td><td>\2</td><td>\3</td><td>\4</td><td>\5</td><td>\6</td><td>\7</td><td>\8</td><td>\9</td></tr>" \
                          "configstart{2}=@param config\n  Configuration string, see @ref config_strings. Permitted values:\n  <table>@hrow{Name,Effect,Values}" \
                          "config{3}=  @row{<tt>\1</tt>,\2,\3}" \
                          "configend=  </table>" \
diff --git a/src/docs/build-pydoc.sh b/src/docs/build-pydoc.sh
index aef88fd4c97..5e6e3635be5 100755
--- a/src/docs/build-pydoc.sh
+++ b/src/docs/build-pydoc.sh
@@ -3,4 +3,4 @@ TOP=$DOCS/..
 . $TOP/config.sh
 
 cd python
-PYTHONPATH=../../lang/python/src:$THRIFT_HOME/lib/python2.7/site-packages pydoc -w wiredtiger
+PYTHONPATH=../../lang/python/src:$THRIFT_HOME/lib/python2.6/site-packages pydoc -w wiredtiger
diff --git a/src/docs/command-line.dox b/src/docs/command-line.dox
index 5726a1d19a1..df52324f8f8 100644
--- a/src/docs/command-line.dox
+++ b/src/docs/command-line.dox
@@ -370,6 +370,19 @@ Include only "fast" statistics in the output (equivalent to passing
 <code>statistics=(fast)</code>) to WT_SESSION::open_cursor.
 
 <hr>
+@section util_truncate wt truncate
+Truncate a table, removing all data.
+
+The \c truncate command truncates the specified \c uri.  It is equivalent to a
+call to WT_SESSION::truncate with no start or stop specified.
+
+@subsection util_truncate_synopsis Synopsis
+<code>wt [-RVv] [-C config] [-E secretkey ] [-h directory] truncate uri</code>
+
+@subsection util_truncate_options Options
+The \c truncate command has no command-specific options.
+
+<hr>
 @section util_upgrade wt upgrade
 Upgrade a table.
 
diff --git a/src/docs/cursor-ops.dox b/src/docs/cursor-ops.dox
index b743d81db57..e479ff29191 100644
--- a/src/docs/cursor-ops.dox
+++ b/src/docs/cursor-ops.dox
@@ -145,9 +145,5 @@ that may not be modified or freed by the application.  If a longer scope
 is required, the application must make a copy of the memory before the
 cursor is re-used, closed or reset.
 
-The comments in this example code explain when the application can safely
-modify memory passed to WT_CURSOR::set_key or WT_CURSOR::set_value:
-
-@snippet ex_scope.c cursor scope operation
 @m_endif
  */
diff --git a/src/docs/cursor-random.dox b/src/docs/cursor-random.dox
index a0a3212be6d..b6434e3d161 100644
--- a/src/docs/cursor-random.dox
+++ b/src/docs/cursor-random.dox
@@ -20,9 +20,4 @@ cursor configured using \c next_random_sample_size divides the object
 into \c next_random_sample_size pieces, and each subsequent retrieval
 returns a record from the next one of those pieces.
 
-For example, setting \c next_random_sample_percent to \c 10 would cause
-the cursor to sequentially return records from each tenth part of the
-object. Setting \c next_random_sample_percent to \c 1000 would cause the
-cursor to sequentially return records from each .1% of the object.
-
  */
diff --git a/src/docs/file-formats.dox b/src/docs/file-formats.dox
index d8990aca7a6..21dc4580bc2 100644
--- a/src/docs/file-formats.dox
+++ b/src/docs/file-formats.dox
@@ -110,7 +110,7 @@ considered.  (See @subpage_single huffman for details.)
 compressing blocks of the backing object's file.  The cost is additional
 CPU and memory use when reading and writing pages to disk.  Note the
 additional CPU cost of block compression can be high, and should be
-considered.   (See @x_ref compression_formats for details.)
+considered.   (See @x_ref compression_considerations for details.)
 
   Block compression is disabled by default.
 
@@ -146,7 +146,7 @@ Huffman encoding can be high, and should be considered.
 compressing blocks of the backing object's file.  The cost is additional
 CPU and memory use when reading and writing pages to disk.  Note the
 additional CPU cost of block compression can be high, and should be
-considered.   (See @x_ref compression_formats for details.)
+considered.   (See @x_ref compression_considerations for details.)
 
   Block compression is disabled by default.
 
@@ -157,7 +157,7 @@ compression: block compression.
 compressing blocks of the backing object's file.  The cost is additional
 CPU and memory use when reading and writing pages to disk.  Note the
 additional CPU cost of block compression can be high, and should be
-considered.   (See @x_ref compression_formats for details.)
+considered.   (See @x_ref compression_considerations for details.)
 
   Block compression is disabled by default.
 
diff --git a/src/docs/programming.dox b/src/docs/programming.dox
index 81e612e8ee8..aa76bef4614 100644
--- a/src/docs/programming.dox
+++ b/src/docs/programming.dox
@@ -66,14 +66,13 @@ each of which is ordered by one or more columns.
 - @subpage_single wtstats
 <p>
 - @subpage_single tune_memory_allocator
-- @subpage_single tune_page_sizes
+- @subpage_single tune_page_size_and_comp
 - @subpage_single tune_cache
 - @subpage_single tune_bulk_load
 - @subpage_single tune_cursor_persist
 - @subpage_single tune_read_only
 - @subpage_single tune_durability
 - @subpage_single tune_checksum
-- @subpage_single tune_compression
 - @subpage_single tune_file_alloc
 - @subpage_single tune_system_buffer_cache
 - @subpage_single tune_transparent_huge_pages
diff --git a/src/docs/spell.ok b/src/docs/spell.ok
index 2413cbc93fb..bc2e16b1122 100644
--- a/src/docs/spell.ok
+++ b/src/docs/spell.ok
@@ -50,6 +50,7 @@ LDFLAGS
 LIBS
 LLVM
 LOGREC
+LRU
 LRVv
 LSB
 LSM
@@ -167,6 +168,7 @@ dNLen
 dNOff
 dT
 dataN
+database's
 dataitem
 dataset
 datasets
diff --git a/src/docs/testing.dox b/src/docs/testing.dox
index cf280e8f3ff..7d454d54212 100644
--- a/src/docs/testing.dox
+++ b/src/docs/testing.dox
@@ -27,7 +27,7 @@ The WiredTiger unit test suite includes tests that cover:
 
 The WiredTiger Python test suite is built using the WiredTiger Python
 API and the Python unittest functionality (the test suite requires at
-least Python version 2.7).
+least Python version 2.6).
 
 The WiredTiger test suite automatically runs as part of every commit
 into the WiredTiger GitHub source tree.
diff --git a/src/docs/top/main.dox b/src/docs/top/main.dox
index 01acc849d50..84487c13174 100644
--- a/src/docs/top/main.dox
+++ b/src/docs/top/main.dox
@@ -6,12 +6,12 @@ WiredTiger is an high performance, scalable, production quality, NoSQL,
 @section releases Releases
 
 <table>
-@row{<b>WiredTiger 2.9.0</b> (current),
+@row{<b>WiredTiger 2.9.1</b> (current),
+	<a href="releases/wiredtiger-2.9.1.tar.bz2"><b>[Release package]</b></a>,
+	<a href="2.9.1/index.html"><b>[Documentation]</b></a>}
+@row{<b>WiredTiger 2.9.0</b> (previous),
 	<a href="releases/wiredtiger-2.9.0.tar.bz2"><b>[Release package]</b></a>,
 	<a href="2.9.0/index.html"><b>[Documentation]</b></a>}
-@row{<b>WiredTiger 2.8.0</b> (previous),
-	<a href="releases/wiredtiger-2.8.0.tar.bz2"><b>[Release package]</b></a>,
-	<a href="2.8.0/index.html"><b>[Documentation]</b></a>}
 @row{<b>Development branch</b>,
 	<a href="https://github.com/wiredtiger/wiredtiger"><b>[Source code]</b></a>,
 	<a href="develop/index.html"><b>[Documentation]</b></a>}
diff --git a/src/docs/transactions.dox b/src/docs/transactions.dox
index bbbd2d52296..3b438eda366 100644
--- a/src/docs/transactions.dox
+++ b/src/docs/transactions.dox
@@ -141,7 +141,7 @@ as if the transaction started at the time of the WT_SESSION::snapshot
 call that created the snapshot.
 
 Named snapshots keep data pinned in cache as if a real transaction were
-running for the time that the named transaction is active.  The resources
+running for the time that the named snapshot is active.  The resources
 associated with named snapshots should be released by calling
 WT_SESSION::snapshot with a configuration that includes
 <code>"drop="</code>. See WT_SESSION::snapshot documentation for details of
diff --git a/src/docs/tune-compression.dox b/src/docs/tune-compression.dox
deleted file mode 100644
index 8db2151aa76..00000000000
--- a/src/docs/tune-compression.dox
+++ /dev/null
@@ -1,62 +0,0 @@
-/*! @page tune_compression Compression
-
-WiredTiger includes a number of optional compression techniques.  Configuring
-compression generally decreases on-disk and in-memory resource requirements
-and the amount of I/O, and increases CPU cost when data are read and written.
-
-Configuring compression may change application throughput.  For example,
-in applications using solid-state drives (where I/O is less expensive),
-turning off compression may increase application performance by reducing
-CPU costs; in applications where I/O costs are more expensive, turning on
-compression may increase application performance by reducing the overall
-number of I/O operations.
-
-An example of turning on row-store key prefix compression:
-
-@snippet ex_all.c Configure key prefix compression on
-
-An example of turning on row-store or column-store dictionary compression:
-
-@snippet ex_all.c Configure dictionary compression on
-
-@section compression_formats Block Compression Formats
-WiredTiger provides two methods of compressing your data when using block
-compression: the raw and noraw methods. These methods change how WiredTiger
-works to fit data into the blocks that are stored on disk.
-
-@subsection noraw_compression Noraw Compression
-Noraw compression is the traditional compression model where a fixed
-amount of data is given to the compression system, then turned into a
-compressed block of data. The amount of data chosen to compress is the
-data needed to fill the uncompressed block. Thus when compressed, the block will
-be smaller than the normal data size and the sizes written to disk will often
-vary depending on how compressible the data being stored is.  Algorithms
-using noraw compression include zlib-noraw, lz4-noraw and snappy.
-
-@subsection raw_compression Raw Compression
-WiredTiger's raw compression takes advantage of compressors that provide a
-streaming compression API. Using the streaming API WiredTiger will try to fit
-as much data as possible into one block. This means that blocks created
-with raw compression should be of similar size. Using a streaming compression
-method should also make for less overhead in compression, as the setup and
-initial work for compressing is done fewer times compared to the amount of
-data stored.  Algorithms using raw compression include zlib, lz4.
-
-@subsection to_raw_or_noraw Choosing between Raw and Noraw Compression
-When looking at which compression method to use the biggest consideration is
-that raw compression will normally provide higher compression levels while
-using more CPU for compression.
-
-An additional consideration is that raw compression may provide a performance
-advantage in workloads where data is accessed sequentially. That is because
-more data is generally packed into each block on disk. Conversely, noraw
-compression may perform better for workloads with random access patterns
-because each block will tend to be smaller and require less work to read and
-decompress.
-
-See @ref file_formats_compression for more information on available
-compression techniques.
-
-See @ref compression for information on how to configure and enable compression.
-
- */
diff --git a/src/docs/tune-page-size-and-comp.dox b/src/docs/tune-page-size-and-comp.dox
new file mode 100644
index 00000000000..96b0fda2333
--- /dev/null
+++ b/src/docs/tune-page-size-and-comp.dox
@@ -0,0 +1,426 @@
+/*! @page tune_page_size_and_comp Tuning page size and compression
+
+This document aims to explain the role played by different page sizes in
+WiredTiger. It also details motivation behind an application wanting to modify
+these page sizes from their default values and the procedure to do so.
+Applications commonly configure page sizes based on their workload's typical key
+and value size. Once a page size has been chosen, appropriate defaults for the
+other configuration values are derived by WiredTiger from the page sizes, and
+relatively few applications will need to modify the other page and key/value
+size configuration options. WiredTiger also offers several compression options
+that have an impact on the size of the data both in-memory and on-disk. Hence
+while selecting page sizes, an application must also look at its desired
+compression needs. Since the data and workload for a table differs from one
+table to another in the database, an application can choose to set page sizes
+and compression options on a per-table basis.
+
+@section data_life_cycle Data life cycle
+Before detailing each page size, here is a review of how data gets stored inside
+WiredTiger:
+ - WiredTiger uses the physical disks to store data durably, creating on-disk
+files for the tables in the database directory. It also caches the portion of
+the table being currently accessed by the application for reading or writing in
+main memory.
+ - WiredTiger maintains a table's data in memory using a data structure called a
+<a href="https://en.wikipedia.org/wiki/B-tree">B-Tree</a> (
+<a href="https://en.wikipedia.org/wiki/B%2B_tree">B+ Tree</a> to be specific),
+referring to the nodes of a B-Tree as pages. Internal pages carry only keys. The
+leaf pages store both keys and values.
+ - The format of the in-memory pages is not the same as the format of the
+on-disk pages.  Therefore, the in-memory pages regularly go through a process
+called reconciliation to create data structures appropriate for storage on the
+disk. These data structures are referred to as on-disk pages. An application can
+set a maximum size separately for the internal and leaf on-disk pages otherwise
+WiredTiger uses a default value. If reconciliation of an in-memory page is
+leading to an on-disk page size greater than this maximum, WiredTiger creates
+multiple smaller on-disk pages.
+ - A component of WiredTiger called the Block Manager divides the on-disk pages
+into smaller chunks called blocks, which then get written to the disk. The size
+of these blocks is defined by a parameter called allocation_size, which is the
+underlying unit of allocation for the file the data gets stored in.  An
+application might choose to have data compressed before it gets stored to disk
+by enabling block compression.
+ - A database's tables are usually much larger than the main memory available.
+Not all of the data can be kept in memory at any given time. A process called
+eviction takes care of making space for new data by freeing the memory of data
+infrequently accessed. An eviction server regularly finds in-memory pages that
+have not been accessed in a while (following an LRU algorithm). Several
+background eviction threads continuously process these pages, reconcile them to
+disk and remove them from the main memory.
+ - When an application does an insert or an update of a key/value pair, the
+associated key is used to refer to an in-memory page. In the case of this page
+not being in memory, appropriate on-disk page(s) are read and an in-memory page
+constructed (the opposite of reconciliation). A data structure is maintained on
+every in-memory page to store any insertions or modifications to the data done
+on that page. As more and more data gets written to this page, the page's memory
+footprint keeps growing.
+ - An application can choose to set the maximum size a page is allowed to grow
+in-memory. A default size is set by WiredTiger if the application doesn't
+specify one. To keep page management efficient, as a page grows larger in-memory
+and approaches this maximum size, if possible, it is split into smaller
+in-memory pages.
+ - When doing an insert or an update, if a page grows larger than the maximum,
+the application thread is used to forcefully evict this page. This is done to
+split the growing page into smaller in-memory pages and reconcile them into
+on-disk pages. Once written to the disk they are removed from the main memory,
+making space for more data to be written. When an application gets involved in
+forced eviction, it might take longer than usual to do these inserts and
+updates. It is not always possible to (force) evict a page from memory and this
+page can temporarily grow larger in size than the configured maximum. This page
+then remains marked to be evicted and reattempts are made as the application
+puts more data in it.
+
+@section configurable_page_struct Configurable page structures in WiredTiger
+There are three page sizes that the user can configure:
+ 1. The maximum page size of any type of in-memory page in the WiredTiger cache,
+memory_page_max.
+ 2. The maximum size of the on-disk page for an internal page, internal_page_max.
+ 3. The maximum size of the on-disk leaf page, leaf_page_max.
+
+There are additional configuration settings that tune more esoteric and
+specialized data. Those are included for completeness but are rarely changed.
+
+@subsection memory_page_max memory_page_max
+The maximum size a table's page is allowed to grow to in memory before being
+reconciled to disk.
+ - An integer, with acceptable values between 512B and 10TB
+ - Default size: 5 MB
+ - Additionally constrained by the condition:
+   leaf_page_max <= memory_page_max <= cache_size/10
+ - Motivation to tune the value:
+\n memory_page_max is significant for applications wanting to tune for
+consistency in write intensive workloads.
+   - This is the parameter to start with for tuning and trying different values
+to find the correct balance between overall throughput and individual operation
+latency for each table.
+   - Splitting a growing in-memory page into smaller pages and reconciliation
+both require exclusive access to the page which makes an application's write
+operations wait. Having a large memory_page_max means that the pages will need
+to be split and reconciled less often. But when that happens, the duration that
+an exclusive access to the page is required is longer, increasing the latency of
+an application's insert or update operations. Conversely, having a smaller
+memory_page_max reduces the time taken for splitting and reconciling the pages,
+but causes it to happen more frequently, forcing more frequent but shorter
+exclusive accesses to the pages.
+   - Applications should choose the memory_page_max value considering the
+trade-off between frequency of exclusive access to the pages (for reconciliation
+or splitting pages into smaller pages) versus the duration that the exclusive
+access is required.
+ - Configuration:
+\n Specified as memory_page_max configuration option to WT_SESSION::create(). An
+example of such a configuration string is as follows:
+
+<pre>
+     "key_format=S,value_format=S,memory_page_max=10MB"
+</pre>
+
+@subsection internal_page_max internal_page_max
+The maximum page size for the reconciled on-disk internal pages of the B-Tree,
+in bytes. When an internal page grows past this size, it splits into multiple
+pages.
+ - An integer, with acceptable values between 512B and 512MB
+ - Default size: 4 KB (*appropriate for applications with relatively small keys)
+ - Additionally constrained by the condition: the size must be a multiple of the
+allocation size
+ - Motivation to tune the value:
+\n internal_page_max is significant for applications wanting to avoid excessive
+L2 cache misses while searching the tree.
+   - Recall that only keys are stored on internal pages, so the type and size of
+the key values for a table help drive the setting for this parameter.
+   - Should be sized to fit into on-chip caches.
+   - Applications doing full-table scans with out-of-memory workloads might
+increase internal_page_max to transfer more data per I/O.
+   - Influences the shape of the B-Tree, i.e. depth and the number of children
+each page in B-Tree has. To iterate to the desired key/value pair in the B-Tree,
+WiredTiger has to binary search the key-range in a page to determine the child
+page to proceed to and continue down the depth until it reaches the correct leaf
+page. Having an unusually deep B-Tree, or having too many children per page can
+negatively impact time taken to iterate the B-Tree, slowing down the application.
+The number of children per page and, hence, the tree depth depends upon the
+number of keys that can be stored in an internal page, which is
+internal_page_max divided by key size. Applications should choose an appropriate
+internal_page_max size that avoids the B-Tree from getting too deep.
+ - Configuration:
+\n Specified as internal_page_max configuration option to WT_SESSION::create().
+An example of such a configuration string is as follows:
+
+<pre>
+     "key_format=S,value_format=S,internal_page_max=16KB,leaf_page_max=1MB"
+</pre>
+
+@subsection leaf_page_max leaf_page_max
+The maximum page size for the reconciled on-disk leaf pages of the B-Tree, in
+bytes. When a leaf page grows past this size, it splits into multiple pages.
+ - An integer, with acceptable values between 512B and 512MB
+ - Default size: 32 KB (*appropriate for applications with relatively small keys
+and values)
+ - Additionally constrained by the condition: must be a multiple of the
+allocation size
+ - Motivation to tune the value:
+\n leaf_page_max is significant for applications wanting to maximize sequential
+data transfer from a storage device.
+   - Should be sized to maximize I/O performance (when reading from disk, it is
+usually desirable to read a large amount of data, assuming some locality of
+reference in the application's access pattern).
+   - Applications doing full-table scans through out-of-cache workloads might
+increase leaf_page_max to transfer more data per I/O.
+   - Applications focused on read/write amplification might decrease the page
+size to better match the underlying storage block size.
+ - Configuration:
+\n Specified as leaf_page_max configuration option to WT_SESSION::create(). An
+example of such a configuration string is as follows:
+
+<pre>
+     "key_format=S,value_format=S,internal_page_max=16KB,leaf_page_max=1MB"
+</pre>
+
+The following configuration items following are rarely used.  They are described
+for completeness:
+
+@subsection allocation_size allocation_size
+This is the underlying unit of allocation for the file. As the unit of file
+allocation, it sets the minimum page size and how much space is wasted when
+storing small amounts of data and overflow items.
+ - an integer between 512B and 128 MB
+ - must a power-of-two
+ - default : 4 KB
+ - Motivation to tune the value:
+\n Most applications should not need to tune the allocation size.
+   - To be compatible with virtual memory page sizes and direct I/O requirements
+on the platform (4KB for most common server platforms)
+   - Smaller values decrease the file space required by overflow items.
+   - For example, if the allocation size is set to 4KB, an overflow item of
+18,000 bytes requires 5 allocation units and wastes about 2KB of space. If the
+allocation size is 16KB, the same overflow item would waste more than 10KB.
+ - Configuration:
+\n Specified as allocation_size configuration option to WT_SESSION::create(). An
+example of such a configuration string is as follows:
+
+<pre>
+     "key_format=S,value_format=S,allocation_size=4KB"
+</pre>
+
+@subsection key_val_max internal/leaf key/value max
+ - Overflow items
+\n Overflow items are keys and values too large to easily store on a page. Overflow
+items are stored separately in the file from the page where the item logically
+appears, and so reading or writing an overflow item is more expensive than an
+on-page item, normally requiring additional I/O.  Additionally, overflow values
+are not cached in memory. This means overflow items won't affect the caching
+behavior of the application.  It also means that each time an overflow value is
+read, it is re-read from disk.
+ - internal_key_max
+\n The largest key stored in an internal page, in bytes. If set, keys larger than
+the specified size are stored as overflow items.
+   - The default and the maximum allowed value are both one-tenth the size of a
+newly split internal page.
+ - leaf_key_max
+\n The largest key stored in a leaf page, in bytes. If set, keys larger than the
+specified size are stored as overflow items.
+   - The default value is one-tenth the size of a newly split leaf page.
+ - leaf_value_max
+\n The largest value stored in a leaf page, in bytes. If set, values larger than
+the specified size are stored as overflow items
+   - The default is one-half the size of a newly split leaf page.
+   - If the size is larger than the maximum leaf page size, the page size is
+temporarily ignored when large values are written.
+ - Motivation to tune the values:
+\n Most applications should not need to tune the maximum key and value sizes.
+Applications requiring a small page size, but also having latency concerns such
+that the additional work to retrieve an overflow item may find modifying these
+values useful.
+\n Since overflow items are separately stored in the on-disk file, aren't cached
+and require additional I/O to access (read or write), applications should avoid
+creating overflow items.
+   - Since page sizes also determine the default size of overflow items, i.e.,
+keys and values too large to easily store on a page, they can be configured to
+avoid performance penalties working with overflow items:
+     - Applications with large keys and values, and concerned with latency,
+might increase the page size to avoid creating overflow items, in order to avoid
+the additional cost of retrieving them.
+     - Applications with large keys and values, doing random searches, might
+decrease the page size to avoid wasting cache space on overflow items that
+aren't likely to be needed.
+     - Applications with large keys and values, doing table scans, might
+increase the page size to avoid creating overflow items, as the overflow items
+must be read into memory in all cases, anyway.
+   - internal_key_max, leaf_key_max and leaf_value_max configuration values
+allow applications to change the size at which a key or value will be treated
+as an overflow item.
+     - Most applications should not need to tune the maximum key and value
+sizes.
+     - The value of internal_key_max is relative to the maximum internal page
+size. Because the number of keys on an internal page determines the depth of the
+tree, the internal_key_max value can only be adjusted within a certain range,
+and the configured value will be automatically adjusted by WiredTiger, if
+necessary, to ensure a reasonable number of keys fit on an internal page.
+     - The values of leaf_key_max and leaf_value_max are not relative to the
+maximum leaf page size. If either is larger than the maximum page size, the page
+size will be ignored when the larger keys and values are being written, and a
+larger page will be created as necessary.
+ - Configuration:
+\n Specified as internal_key_max, leaf_key_max and leaf_value_max configuration
+options to WT_SESSION::create(). An example of configuration string for a large
+leaf overflow value:
+
+<pre>
+     "key_format=S,value_format=S,leaf_page_max=16KB,leaf_value_max=256KB"
+</pre>
+
+@subsection split_pct split_pct (split percentage)
+The size (specified as percentage of internal/leaf page_max) at which the
+reconciled page must be split into multiple smaller pages before being sent for
+compression and then be written to the disk. If the reconciled page can fit into
+a single on-disk page without the page growing beyond it's set max size,
+split_pct is ignored and the page isn't split.
+ - an integer between 25 and 100
+ - default : 75
+ - Motivation to tune the value:
+\n Most applications should not need to tune the split percentage size.
+   - This value should be selected to avoid creating a large number of tiny
+pages or repeatedly splitting whenever new entries are inserted.
+\n For example, if the maximum page size is 1MB, a split_pct value of 10%
+would potentially result in creating a large number of 100KB pages, which may
+not be optimal for future I/O. Or, if the maximum page size is 1MB, a split_pct
+value of 90% would potentially result in repeatedly splitting pages as the split
+pages grow to 1MB over and over. The default value for split_pct is 75%,
+intended to keep large pages relatively large, while still giving split pages
+room to grow.
+ - Configuration:
+\n Specified as split_pct configuration option to WT_SESSION::create(). An
+example of such a configuration string is as follows:
+
+<pre>
+     "key_format=S,value_format=S,split_pct=60"
+</pre>
+
+@section compression_considerations Compression considerations
+WiredTiger compresses data at several stages to preserve memory and disk space.
+Applications can configure these different compression algorithms to tailor
+their requirements between memory, disk and CPU consumption. Compression
+algorithms other than block compression work by modifying how the keys and
+values are represented, and hence reduce data size in-memory and on-disk. Block
+compression on the other hand compress the data in its binary representation
+while saving it on the disk.
+
+Configuring compression may change application throughput. For example, in
+applications using solid-state drives (where I/O is less expensive), turning
+off compression may increase application performance by reducing CPU costs; in
+applications where I/O costs are more expensive, turning on compression may
+increase application performance by reducing the overall number of I/O
+operations.
+
+WiredTiger uses some internal algorithms to compress the amount of data stored
+that are not configurable, but always on.  For example, run-length reduces the
+size requirement by storing sequential, duplicate values in the store only a
+single time (with an associated count).
+
+Different compression options available with WiredTiger:
+ - Key-prefix
+   - Reduces the size requirement by storing any identical key prefix only once
+per page. The cost is additional CPU and memory when operating on the in-memory
+tree. Specifically, reverse sequential cursor movement (but not forward) through
+a prefix-compressed page or the random lookup of a key/value pair will allocate
+sufficient memory to hold some number of uncompressed keys. So, for example, if
+key prefix compression only saves a small number of bytes per key, the
+additional memory cost of instantiating the uncompressed key may mean prefix
+compression is not worthwhile. Further, in cases where the on-disk cost is the
+primary concern, block compression may mean prefix compression is less useful.
+   - Configuration:
+\n Specified as prefix_compression configuration option to
+WT_SESSION::create(). Applications may limit the use of prefix compression by
+configuring the minimum number of bytes that must be gained before prefix
+compression is used with prefix_compression_min configuration option. An example
+of such a configuration string is as follows:
+
+<pre>
+          "key_format=S,value_format=S,prefix_compression=true,prefix_compression_min=7"
+</pre>
+
+ - Dictionary
+   - Reduces the size requirement by storing any identical value only once per
+page.
+   - Configuration:
+\n Specified as dictionary configuration configuration option to
+WT_SESSION::create(), which specifies the maximum number of unique values
+remembered in the B-Tree row-store leaf page value dictionary. An example of
+such a configuration string is as follows:
+
+<pre>
+          "key_format=S,value_format=S,dictionary=1000"
+</pre>
+
+ - Huffman
+   - Reduces the size requirement by compressing individual key/value items, and
+can be separately configured either or both keys and values. The additional CPU
+cost of Huffman encoding can be high, and should be considered. (See Huffman
+Encoding for details.)
+   - Configuration:
+\n Specified as huffman_key and/or huffman_value configuration option to
+WT_SESSION::create(). These options can take values of "english" (to use a
+built-in English language frequency table), "utf8<file>" or "utf16<file>" (to
+use a custom utf8 or utf16 symbol frequency table file). An example of such a
+configuration string is as follows:
+
+<pre>
+          "key_format=S,value_format=S,huffman_key=english,huffman_value=english"
+</pre>
+
+ - Block Compression
+   - Reduces the size requirement of on-disk objects by compressing blocks of
+the backing object's file. The additional CPU cost of block compression can be
+high, and should be considered. When block compression has been configured,
+configured page sizes will not match the actual size of the page on disk.
+   - WiredTiger provides two methods of compressing your data when using block
+compression: the raw and noraw methods. These methods change how WiredTiger
+works to fit data into the blocks that are stored on disk. Applications needing
+to write specific sized blocks may want to consider implementing a
+WT_COMPRESSOR::compress_raw function.
+   - Noraw compression:
+\n A fixed amount of data is given to the compression system, then turned into
+a compressed block of data. The amount of data chosen to compress is the data
+needed to fill the uncompressed block. Thus when compressed, the block will be
+smaller than the normal data size and the sizes written to disk will often vary
+depending on how compressible the data being stored is. Algorithms using noraw
+compression include zlib-noraw, lz4-noraw and snappy.
+Noraw compression is better suited for workloads with random access patterns
+because each block will tend to be smaller and require less work to read and
+decompress.
+   - Raw compression:
+\n WiredTiger's raw compression takes advantage of compressors that provide a
+streaming compression API. Using the streaming API WiredTiger will try to fit as
+much data as possible into one block. This means that blocks created with raw
+compression should be of similar size. Using a streaming compression method
+should also make for less overhead in compression, as the setup and initial work
+for compressing is done fewer times compared to the amount of data stored.
+Algorithms using raw compression include zlib, lz4.
+Compared to noraw, raw compression provides more compression while using more
+CPU. Raw compression may provide a performance advantage in workloads where data
+is accessed sequentially. That is because more data is generally packed into
+each block on disk.
+   - Configuration:
+\n Specified as the block_compressor configuration option to
+WT_SESSION::create(). If WiredTiger has builtin support for "lz4", "snappy",
+"zlib" or "zstd" compression, these names are available as the value to the
+option. An example of such a configuration string is as follows:
+
+<pre>
+          "key_format=S,value_format=S,block_compressor=snappy"
+</pre>
+
+See @ref compression for further information on how to configure and enable
+different compression options.
+
+@subsection table_compress Table summarizing compression in WiredTiger
+
+<table>
+@hrow{Compression Type, Supported by row-store, Supported by variable col-store,
+      Supported by fixed col-store, Default config, Reduces in-mem size,
+      Reduces on-disk size, CPU and Memory cost}
+@row{Key-prefix, yes, no, no, disabled, yes, yes, minor}
+@row{Dictionary, yes, yes, no, disabled, yes, yes, minor}
+@row{Huffman, yes, yes, no, disabled, yes, yes, can be high}
+@row{Block, yes, yes, yes, disabled, no, yes, can be high}
+</table>
+
+*/
diff --git a/src/docs/tune-page-sizes.dox b/src/docs/tune-page-sizes.dox
deleted file mode 100644
index 130e047a02d..00000000000
--- a/src/docs/tune-page-sizes.dox
+++ /dev/null
@@ -1,142 +0,0 @@
-/*! @page tune_page_sizes  Page and overflow key/value sizes
-
-There are seven page and key/value size configuration strings:
-
-- allocation size (\c allocation_size),
-- page sizes (\c internal_page_max and \c leaf_page_max),
-- key and value sizes (\c internal_key_max, \c leaf_key_max and \c leaf_value_max), and the
-- page-split percentage (\c split_pct).
-
-All seven are specified to the WT_SESSION::create method, in other
-words, they are configurable on a per-file basis.
-
-Applications commonly configure page sizes, based on their workload's
-typical key and value size. Once the correct page size has been chosen,
-appropriate defaults for the other configuration values are derived from
-the page sizes, and relatively few applications will need to modify the
-other page and key/value size configuration options.
-
-An example of configuring page and key/value sizes:
-
-@snippet ex_all.c Create a table and configure the page size
-
-@section tune_page_sizes_sizes Page, key and value sizes
-
-The \c internal_page_max and \c leaf_page_max configuration values
-specify a maximum size for Btree internal and leaf pages.  That is, when
-an internal or leaf page grows past that size, it splits into multiple
-pages.  Generally, internal pages should be sized to fit into on-chip
-caches in order to minimize cache misses when searching the tree, while
-leaf pages should be sized to maximize I/O performance (if reading from
-disk is necessary, it is usually desirable to read a large amount of
-data, assuming some locality of reference in the application's access
-pattern).
-
-The default page size configurations (2KB for \c internal_page_max, 32KB
-for \c leaf_page_max), are appropriate for applications with relatively
-small keys and values.
-
-- Applications doing full-table scans through out-of-memory workloads
-might increase both internal and leaf page sizes to transfer more data
-per I/O.
-- Applications focused on read/write amplification might decrease the page
-size to better match the underlying storage block size.
-
-When block compression has been configured, configured page sizes will
-not match the actual size of the page on disk. Block compression in
-WiredTiger happens within the I/O subsystem, and so a page might split
-even if subsequent compression would result in a resulting page size
-small enough to leave as a single page.  In other words, page sizes are
-based on in-memory sizes, not on-disk sizes. Applications needing to
-write specific sized blocks may want to consider implementing a
-WT_COMPRESSOR::compress_raw function.
-
-The page sizes also determine the default size of overflow items, that
-is, keys and values too large to easily store on a page.  Overflow items
-are stored separately in the file from the page where the item logically
-appears, and so reading or writing an overflow item is more expensive
-than an on-page item, normally requiring additional I/O.  Additionally,
-overflow values are not cached in memory. This means overflow items
-won't affect the caching behavior of the application, but it also means
-that each time an overflow value is read, it is re-read from disk.
-
-For both of these reasons, applications should avoid creating large
-numbers of commonly referenced overflow items.  This is especially
-important for keys, as keys on internal pages are referenced during
-random searches, not just during data retrieval.  Generally,
-applications should make every attempt to avoid creating overflow keys.
-
-- Applications with large keys and values, and concerned with latency,
-might increase the page size to avoid creating overflow items, in order
-to avoid the additional cost of retrieving them.
-
-- Applications with large keys and values, doing random searches, might
-decrease the page size to avoid wasting cache space on overflow items
-that aren't likely to be needed.
-
-- Applications with large keys and values, doing table scans, might
-increase the page size to avoid creating overflow items, as the overflow
-items must be read into memory in all cases, anyway.
-
-The \c internal_key_max, \c leaf_key_max and \c leaf_value_max
-configuration values allow applications to change the size at which a
-key or value will be treated as an overflow item.
-
-The value of \c internal_key_max is relative to the maximum internal
-page size.  Because the number of keys on an internal page determines
-the depth of the tree, the \c internal_key_max value can only be
-adjusted within a certain range, and the configured value will be
-automatically adjusted by WiredTiger, if necessary to ensure a
-reasonable number of keys fit on an internal page.
-
-The values of \c leaf_key_max and \c leaf_value_max are not relative to
-the maximum leaf page size. If either is larger than the maximum page
-size, the page size will be ignored when the larger keys and values are
-being written, and a larger page will be created as necessary.
-
-Most applications should not need to tune the maximum key and value
-sizes.  Applications requiring a small page size, but also having
-latency concerns such that the additional work to retrieve an overflow
-item is an issue, may find them useful.
-
-An example of configuring a large leaf overflow value:
-
-@snippet ex_all.c Create a table and configure a large leaf value max
-
-@section tune_page_sizes_split_percentage Split percentage
-
-The \c split_pct configuration string configures the size of a split
-page.  When a page grows sufficiently large that it must be written as
-multiple disk blocks, the newly written block size is \c split_pct
-percent of the maximum page size.  This value should be selected to
-avoid creating a large number of tiny pages or repeatedly splitting
-whenever new entries are inserted.  For example, if the maximum page
-size is 1MB, a \c split_pct value of 10% would potentially result in
-creating a large number of 100KB pages, which may not be optimal for
-future I/O.   Or, if the maximum page size is 1MB, a \c split_pct value
-of 90% would potentially result in repeatedly splitting pages as the
-split pages grow to 1MB over and over.  The default value for \c
-split_pct is 75%, intended to keep large pages relatively large, while
-still giving split pages room to grow.
-
-Most applications should not need to tune the split percentage size.
-
-@section tune_page_sizes_allocation_size Allocation size
-
-The \c allocation_size configuration value is the underlying unit of
-allocation for the file.  As the unit of file allocation, it sets the
-minimum page size and how much space is wasted when storing small
-amounts of data and overflow items.  For example, if the allocation size
-is set to 4KB, an overflow item of 18,000 bytes requires 5 allocation
-units and wastes about 2KB of space.  If the allocation size is 16KB,
-the same overflow item would waste more than 10KB.
-
-The default allocation size is 4KB, chosen for compatibility with
-virtual memory page sizes and direct I/O requirements on common server
-platforms.
-
-Most applications should not need to tune the allocation size; it is
-primarily intended for applications coping with the specific
-requirements some file systems make to support features like direct I/O.
-
-*/
diff --git a/src/docs/upgrading.dox b/src/docs/upgrading.dox
index 1e0e2eaf99a..e5fce3d0d5d 100644
--- a/src/docs/upgrading.dox
+++ b/src/docs/upgrading.dox
@@ -1,22 +1,66 @@
 /*! @page upgrading Upgrading WiredTiger applications
-@section version_291 Upgrading to Version 2.9.1
+
+@section version_292 Upgrading to Version 2.9.2
 <dl>
-<dt>WiredTiger now requires Python 2.7 at minimum</dt>
+
+<dt>WiredTiger utility now supports truncate</dt>
+<dd>
+The WiredTiger utility \c wt can now \c truncate objects, removing all
+contents from the specified object.
+</dd>
+
+<dt>Handle list lock statistics</dt>
 <dd>
-The minimum version of Python supported by WiredTiger is now 2.7 up from the
-previous version of 2.6. This is due to extra unit tests added in this release
-that depend on 2.7. This is not due to a change in the Python API.
+In the 2.9.1 release we added statistics tracking handle list lock timing, we
+have switched that lock from a spin lock to a read-write lock, and consequently
+changed the statistics tracking lock related wait time.
 </dd>
 
+<dt>Forced and named checkpoint error conditions changed</dt>
+<dd>
+There are new cases where checkpoints created with an explicit name or the
+"force" configuration option can return an EBUSY error. This can happen if
+the checkpoint overlaps with other schema operations, for example table create.
+</dd>
+
+<dt>WT_CURSOR::remove may not return a positioned cursor</dt>
+<dd>
+The WT_CURSOR::remove method was previously documented to always return a
+positioned cursor on success, which is not possible when \c overwrite=true
+and the record does not exist.
+
+The documentation has been updated, and the method has been changed to
+never return a cursor position unless called with an existing cursor
+position. In other words, if the cursor is positioned and the
+WT_CURSOR::remove is called, the cursor will remain positioned; if the
+cursor is not positioned and the WT_CURSOR::remove method is called, the
+cursor will not be positioned on return.
+</dd>
+
+</dl><hr>
+@section version_291 Upgrading to Version 2.9.1
+<dl>
+
 <dt>Changes to hazard pointer configuration</dt>
 <dd>
 The \c hazard_max parameter to ::wiredtiger_open is now ignored.  Memory is
 allocated for hazard pointers as required by each session.
 </dd>
-</dl><hr>
 
+<dt>Change to the default fadvise behavior for data files</dt>
+<dd>
+The old default behavior was to advise the file system that access would be
+random for data files, and there was no way to alter that. We no longer
+call advise the file system of expected access patterns by default, and
+have added a new \c access_pattern_hint configuration option available for
+WT_SESSION::create that can be used to restore the old default by setting
+the value to "random".
+</dd>
+
+</dl><hr>
 @section version_290 Upgrading to Version 2.9.0
 <dl>
+
 <dt>Changes to cursor behavior after WT_CURSOR::insert</dt>
 <dd>
 After a successful call to WT_CURSOR::insert, unless a cursor has record
@@ -314,7 +358,7 @@ be updated.
 The WT_SESSION::create \c internal_item_max and \c leaf_item_max
 configuration strings are now deprecated in favor of the
 \c internal_key_max, \c leaf_key_max, and \c leaf_value_max
-configuration strings. See @ref tune_page_sizes for more information.
+configuration strings. See @ref tune_page_size_and_comp for more information.
 </dd>
 
 </dl><hr>
diff --git a/src/docs/wtperf.dox b/src/docs/wtperf.dox
index 83aadf8a776..6bdcf5f4f8d 100644
--- a/src/docs/wtperf.dox
+++ b/src/docs/wtperf.dox
@@ -167,6 +167,8 @@ do population phase; false to use existing database
 number of WiredTiger databases to use. Each database will execute the  workload using a separate home directory and complete set of worker  threads
 @par drop_tables (boolean, default=false)
 Whether to drop all tables at the end of the run, and report time taken  to do the drop.
+@par in_memory (boolean, default=false)
+Whether to create the database in-memory.
 @par icount (unsigned int, default=5000)
 number of records to initially populate. If multiple tables are  configured the count is spread evenly across all tables.
 @par idle_table_cycle (unsigned int, default=0)
@@ -195,14 +197,14 @@ use pareto distribution for random numbers. Zero  to disable, otherwise a percen
 number of operations to group into each transaction in the populate  phase, zero for auto-commit
 @par populate_threads (unsigned int, default=1)
 number of populate threads, 1 for bulk load
+@par pre_load_data (boolean, default=false)
+Scan all data prior to starting the workload phase to warm the cache
 @par random_range (unsigned int, default=0)
 if non zero choose a value from within this range as the key for  insert operations
 @par random_value (boolean, default=false)
 generate random content for the value
 @par range_partition (boolean, default=false)
 partition data by range (vs hash)
-@par read_range (unsigned int, default=0)
-scan a range of keys after each search
 @par readonly (boolean, default=false)
 reopen the connection between populate and workload phases in readonly  mode.  Requires reopen_connection turned on (default).  Requires that  read be the only workload specified
 @par reopen_connection (boolean, default=true)
@@ -228,7 +230,7 @@ number of tables to run operations over. Keys are divided evenly  over the table
 @par table_count_idle (unsigned int, default=0)
 number of tables to create, that won't be populated. Default 0.
 @par threads (string, default="")
-workload configuration: each 'count'  entry is the total number of threads, and the 'insert', 'read' and  'update' entries are the ratios of insert, read and update operations  done by each worker thread; If a throttle value is provided each thread  will do a maximum of that number of operations per second; multiple  workload configurations may be specified per threads configuration;  for example, a more complex threads configuration might be  'threads=((count=2,reads=1)(count=8,reads=1,inserts=2,updates=1))'  which would create 2 threads doing nothing but reads and 8 threads  each doing 50% inserts and 25% reads and updates.  Allowed configuration  values are 'count', 'throttle', 'update_delta', 'reads', 'inserts',  'updates', 'truncate', 'truncate_pct' and 'truncate_count'. There are  also behavior modifiers, supported modifiers are 'ops_per_txn'
+workload configuration: each 'count'  entry is the total number of threads, and the 'insert', 'read' and  'update' entries are the ratios of insert, read and update operations  done by each worker thread; If a throttle value is provided each thread  will do a maximum of that number of operations per second; multiple  workload configurations may be specified per threads configuration;  for example, a more complex threads configuration might be  'threads=((count=2,reads=1)(count=8,reads=1,inserts=2,updates=1))'  which would create 2 threads doing nothing but reads and 8 threads  each doing 50% inserts and 25% reads and updates.  Allowed configuration  values are 'count', 'throttle', 'update_delta', 'reads', 'read_range',  'inserts', 'updates', 'truncate', 'truncate_pct' and 'truncate_count'.  There are also behavior modifiers, supported modifiers are  'ops_per_txn'
 @par transaction_config (string, default="")
 WT_SESSION.begin_transaction configuration string, applied during the  populate phase when populate_ops_per_txn is nonzero
 @par table_name (string, default="test")