bk commit - mysqldoc tree (marko:1.2873)

[Marko Mäkelä]

Below is the list of changes that have just been committed into a local
mysqldoc repository of marko. When marko does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://www.mysql.com/doc/I/n/Installing_source_tree.html

ChangeSet
  1.2873 05/04/18 10:39:29 marko@stripped +1 -0
  manual.texi:
    Server system variables: Remove duplicate innodb_max_purge lag
    and move innodb_table_locks to alphabetically ordered position.
    InnoDB Multi-Versioning, InnoDB start: Move the description of
    innodb_max_purge_lag to @node InnoDB start, as suggested by Peter Zaitsev.

  Docs/manual.texi
    1.2705 05/04/18 10:36:54 marko@stripped +21 -25
    Server system variables: Remove duplicate innodb_max_purge lag
    and move innodb_table_locks to alphabetically ordered position.
    InnoDB Multi-Versioning, InnoDB start: Move the description of
    innodb_max_purge_lag to @node InnoDB start, as suggested by Peter Zaitsev.

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	marko
# Host:	hundin.mysql.fi
# Root:	/home/marko/k/mysqldoc

--- 1.2704/Docs/manual.texi	Mon Apr 18 10:11:36 2005
+++ 1.2705/Docs/manual.texi	Mon Apr 18 10:36:54 2005
@@ -20450,7 +20450,6 @@
 | innodb_max_dirty_pages_pct      | 90                                                          |
 | innodb_max_purge_lag            | 0                                                           |
 | innodb_table_locks              | ON                                                          |
-| innodb_max_purge_lag            | 0                                                           |
 | innodb_mirrored_log_groups      | 1                                                           |
 | innodb_open_files               | 300                                                         |
 | innodb_thread_concurrency       | 8                                                           |
@@ -67451,13 +67450,26 @@
 
 @item innodb_max_purge_lag
 This option controls how to delay @code{INSERT}, @code{UPDATE}
-and @code{DELETE} operations when the purge operations are lagging.
-The default value of this parameter is zero, meaning that there
-are no delays. When the value is greater than zero, @code{InnoDB}
-may delay new row operations, as described in @ref{InnoDB Multi-Versioning}.
-This option can be changed at runtime as a global system variable.
+and @code{DELETE} operations when the purge operations
+(@pxref{InnoDB Multi-Versioning}) are lagging.  The default value of
+this parameter is zero, meaning that there are no delays.  This option
+can be changed at runtime as a global system variable.
 @code{innodb_max_purge_lag} is available as of MySQL 4.0.22 and 4.1.6.
 
+The InnoDB transaction system maintains a list of transactions that
+have delete-marked index records by @code{UPDATE} or @code{DELETE}
+operations.  Let the length of this list be @var{purge_lag}.  When
+@var{purge_lag} exceeds @code{innodb_max_purge_lag}, each
+@code{INSERT}, @code{UPDATE} and @code{DELETE} operation is delayed by
+((@var{purge_lag}/@code{innodb_max_purge_lag})*10)-5 milliseconds.
+The delay is computed in the beginning of a purge batch, every ten
+seconds.  The operations are not delayed if purge cannot run because
+of an old consistent read view that could see the rows to be purged.
+
+A typical setting for a problematic workload might be 1 million,
+assuming that our transactions are small, only 100 bytes in size, and
+we can allow @w{100 MB} of unpurged rows in our tables.
+
 @item innodb_mirrored_log_groups
 The number of identical copies of log groups we keep for the
 database. Currently this should be set to 1.
@@ -69821,25 +69833,9 @@
 would carry just @w{10 MB} of useful data, it may grow to occupy
 @w{10 GB} with all the dead rows.  In such a case, it would be good
 to throttle new row operations, and allocate more resources for the
-purge thread.
-
-The InnoDB transaction system maintains a list of transactions that
-have delete-marked index records by @code{UPDATE} or @code{DELETE}
-operations.  Let the length of this list be @var{purge_lag}.
-
-Starting with MySQL/InnoDB-4.1.6 and 4.0.22, there is a startup option
-and settable global variable @code{innodb_max_purge_lag}, which is
-zero by default.  When this parameter is non-zero, InnoDB may delay new
-row operations.  When the @var{purge_lag} exceeds
-@code{innodb_max_purge_lag}, each @code{INSERT}, @code{UPDATE} and
-@code{DELETE} operation is delayed by
-((@var{purge_lag}/@code{innodb_max_purge_lag})*10)-5 milliseconds.  The
-delay is computed in the beginning of a purge batch, every ten
-seconds.  The operations are not delayed if purge cannot run
-because of an old consistent read view that could see the rows to be
-purged.  A typical setting for a problematic workload might be 1
-million, assuming that our transactions are small, only 100 bytes in
-size, and we can allow @w{100 MB} of unpurged rows in our tables.
+purge thread.  Starting with MySQL/InnoDB-4.1.6 and 4.0.22, there is a
+startup option and settable global variable
+@code{innodb_max_purge_lag} for exactly this purpose.  @xref{InnoDB start}.
 
 @node Table and index, File space management, InnoDB Multi-Versioning, InnoDB
 @section Table and Index Structures