Merge zgreant@work.mysql.com:/home/bk/mysql-4.0

into mysql.com:/home/zak/Work/bk/mysql-4.0

BitKeeper/etc/logging_ok

@@ -69,3 +69,4 @@ zak@balfor.local
 zak@linux.local
 salle@geopard.(none)
 walrus@mysql.com
+zgreant@mysql.com

Docs/manual.texi

@@ -30674,12 +30674,12 @@ mysql> SELECT INTERVAL(22, 23, 30, 44, 200);
 @end example
 @end table
 
-If you are comparing case-sensitive string with any of the standard
-operators (@code{=}, @code{<>}..., but not @code{LIKE}) end space will
-be ignored.
+If you are comparing case-insensitive strings with any of the standard
+operators (@code{=}, @code{<>}..., but not @code{LIKE}) trailing whitespace 
+(spaces, tabs and newlines) will be ignored.
 
 @example
-mysql> SELECT "a" ="A ";
+mysql> SELECT "a" ="A \n";
         -> 1
 @end example
 
@@ -36874,28 +36874,26 @@ parameters to @code{FULLTEXT} in @code{CREATE/ALTER TABLE}).
 
 From version 4.0.1, @code{MySQL server} features a @code{Query Cache}.
 When in use, the query cache stores the text of a @code{SELECT} query
-together with the corresponding result that is sent to a client.
-If another identical query is received, the server can then retrieve
+together with the corresponding result that was sent to the client.
+If an identical query is later received, the server will retrieve
 the results from the query cache rather than parsing and executing the
 same query again.
 
+@strong{NOTE:} The query cache does not return stale data. When data
+is modified, any relevant entries in the query cache are flushed.
+
 The query cache is extremely useful in an environment where (some)
 tables don't change very often and you have a lot of identical queries.
 This is a typical situation for many web servers that use a lot of
 dynamic content.
 
-Following are some performance data for the query cache
-(We got these by running the MySQL benchmark suite on a Linux Alpha
-2x500 MHz with 2GB RAM and a 64MB query cache):
+Below is some performance data for the query cache. (These results were 
+generated by running the MySQL benchmark suite on a Linux Alpha
+2 x 500 MHz with 2GB RAM and a 64MB query cache):
 
 @itemize @bullet
 @item
-If you want to disable the query cache code set @code{query_cache_size=0}.
-By disabling the query cache code there is no noticeable overhead.
-(query cache can be excluded from code with help of configure option
-@code{--without-query-cache}) 
-@item
-If all of the queries you're preforming are simple (such as selecting a
+If all of the queries you're performing are simple (such as selecting a
 row from a table with one row); but still differ so that the queries can
 not be cached, the overhead for having the query cache active is 13%.
 This could be regarded as the worst case scenario. However, in real life,
@@ -36905,6 +36903,11 @@ is normally significantly lower.
 Searches after one row in a one row table is 238% faster.
 This can be regarded as close to the minimum speedup to be expected for
 a query that is cached.
+@item
+If you want to disable the query cache code set @code{query_cache_size=0}.
+By disabling the query cache code there is no noticeable overhead.
+(query cache can be excluded from code with help of configure option
+@code{--without-query-cache})
 @end itemize
 
 @menu