From 80c5f4fdd35843a28508d7687f065aa7bcd74472 Mon Sep 17 00:00:00 2001
From: "arjen@fred.bitbike.com" <>
Date: Tue, 19 Mar 2002 15:47:24 +1000
Subject: [PATCH] Some rephrasing, based on suggestions by Egor.

---
 Docs/manual.texi | 27 +++++++++++++--------------
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/Docs/manual.texi b/Docs/manual.texi
index 4e4a60ee6b4..7bcb2725ac6 100644
--- a/Docs/manual.texi
+++ b/Docs/manual.texi
@@ -3187,9 +3187,10 @@ This can be handled much more efficiently by using an
 
 @cindex rows, locking
 @cindex locking, row-level
-Generally, you can code around row-level locking. Some cases really
-need it, but they are very few. For instance, you can use a flag
-column in the table and do something like this:
+You can generally code around row-level locking. Some situations really
+need it, but they are very few. @code{InnoDB} tables support row-level
+locking. With MyISAM, you can use a flag column in the table and do
+something like the following:
 
 @example
 UPDATE tbl_name SET row_flag=1 WHERE id=ID;
@@ -55410,22 +55411,20 @@ In MySQL, common tags to print (with the @code{d} option) are:
 @cindex methods, locking
 
 Currently MySQL only supports table locking for
-@code{ISAM}/@code{MyISAM} and @code{HEAP} tables.
-@code{InnoDB} tables use row level locking,
-and @code{BDB} tables page level locking. @xref{Internal locking}.
-With @code{MyISAM}
-tables one can freely mix @code{INSERT} and @code{SELECT} without locks
-(@code{Versioning}).
+@code{ISAM}/@code{MyISAM} and @code{HEAP} tables,
+page-level locking for @code{BDB} tables and
+row-level locking for @code{InnoDB} tables.
+@xref{Internal locking}.
+With @code{MyISAM} tables one can freely mix @code{INSERT} and
+@code{SELECT} without locks (@code{Versioning}).
 
 Starting in version 3.23.33, you can analyse the table lock contention
 on your system by checking @code{Table_locks_waited} and
 @code{Table_locks_immediate} environment variables.
 
-Some database users claim that MySQL cannot support near the
-number of concurrent users because it lacks row-level locking.  This
-may be true for some specific applications, but is not generally
-true. As always this depends totally on what the application does and what
-is the access/update pattern of the data.
+To decide if you want to use a table type with row-level locking,
+you will want to look at what the application does and what the
+select/update pattern of the data is.
 
 Pros for row locking: