Author: jstephens
Date: 2005-10-20 05:28:50 +0200 (Thu, 20 Oct 2005)
New Revision: 117

Log:

refman-common/news-4.1.xml - Documented fix for Bug#12915
refman-common/news-5.0.xml - Documented fix for Bug#12915

refman-5.0/introduction.xml - Added back list of preformance enhancements to 5.0 Intro which I
originally added on 2005-10-12 (revision 32) *as requested by Monty*, and which someone appears
to have removed afterwards.

Please do not remove this listing again without consulting me. Thanks. //jon.



Modified:
trunk/refman-5.0/introduction.xml
trunk/refman-common/news-4.1.xml
trunk/refman-common/news-5.0.xml

Modified: trunk/refman-5.0/introduction.xml
===================================================================
--- trunk/refman-5.0/introduction.xml 2005-10-20 01:22:32 UTC (rev 116)
+++ trunk/refman-5.0/introduction.xml 2005-10-20 03:28:50 UTC (rev 117)
@@ -101,15 +101,13 @@
.


+
+
+
+ For future plans, see .
+
+

-
-


For a list of all the contributors to this project, see
@@ -507,15 +505,220 @@
.


+
+
+
+ Performance enhancements:
+ A number of improvements were made in MySQL 5.0 to improve
+ the speed of certain types of queries and in the handling of
+ certain types. These include:
+
+
+
+
+
+ Improved handling of multi-table joins even where
+ there are no good keys to use.
+
+
+
+
+
+ Better optimization of OR over
+ different keys, such as ... WHERE key1=5 OR
+ key2=6. (Previously, OR
+ was optimized only where both relations involved the
+ same key.) This also applies to other one-to-one
+ comparison operators (>,
+ <, and so on), as well as
+ =.
+
+
+
+
+
+ New equality detector that finds and optimizes
+ hidden equalities in joins. This includes
+ queries of the form
+
+
+
+SELECT * FROM t1,t2,t3
+ WHERE t1.a=t2.a AND t2.a=t3.a
+
+
+
+ as well as
+

+
+SELECT * FROM t1,t2
+ WHERE t1.a=t2.c AND t1.b=t2.d AND t2.d BETWEEN i AND j;
+
+
+
+ where a, b,
+ c, and d are
+ indexed columns, and i and
+ j are constant values.
+
+
+
+
+
+ Optimization of NOT IN and
+ NOT BETWEEN relations, reducing or
+ eliminating table scans for queries making use of these.
+
+
+
+
+
+ The VARCHAR data type as implemented
+ in MySQL 5.0 is more efficient than in previous
+ versions, due to the elimination of the old (and
+ nonstandard) removal of trailing spaces during retrival.
+
+
+
+
+
+ The addition of a true BIT column
+ type; this type is much more efficient for storage and
+ retrieval of Boolean values than the workarounds
+ required in MySQL in versions previous to 5.0.
+
+
+
+
+
+ Performance Improvements in the
+ InnoDB Storage Engine:
+
+
+
+
+
+ New compact storage format which can save up to 20%
+ of the disk space required in previous
+ MySQL/InnoDB versions.
+
+
+
+
+
+ Faster recovery from a failed or aborted ALTER
+ TABLE.
+
+
+
+
+
+ Faster implementation of TRUNCATE.
+
+
+
+
+
+ (See .)
+
+
+
+
+
+ Performance Improvements in the
+ NDBCluster Storage Engine:
+
+
+
+
+
+ Faster handling of queries that use
+ IN and BETWEEN.
+
+
+
+
+
+ Condition pushdown:
+ In cases involving the comparison of an unindexed
+ column with a constant, this condition is
+ pushed down to the cluster where it
+ is evaluated in all partitions
+ simultaneously, eliminating the need to send
+ non-matching records over the network. This can make
+ such queries 10 to 100 times faster than in MySQL
+ 4.1 Cluster.
+
+
+
+
+
+ (See .)
+
+
+
+
+
+ COUNT(DISTINCT) is made faster in
+ cases not involving BLOB columns
+ through the use of a temporary file rather than a
+ temporary table.
+
+
+
+ MIN() and MAX()
+ with GROUP BY are also now better
+ optimized.
+
+
+
+
+
+ The performance of the MySQL client library is increased
+ through the use of a receive buffer that greatly reduces
+ the number of system calls which the library needs to
+ make. This can speed up the retrieval of large result
+ sets by a factor of 2.
+
+
+
+
+
+ Null keys can be pre-eliminated in many
+ cases, speeding up COUNT(*) queries.
+ An example of such a query might be
+
+
+
+SELECT COUNT(*) FROM t1,t2 WHERE t2.c=t1.a;
+
+
+ where c is an indexed column allowing
+ NULL values.
+
+
+
+
+
+ Single-table UPDATE or
+ DELETE queries containing an
+ ORDER BY ... LIMIT
+ N clause (but not
+ having any WHERE clause) can now take
+ advantage of an index to read only the first
+ N records, as opposed to
+ scanning the entire table.
+
+
+
+
+
+
+



- For more detailed information on changes in MySQL 5.0, see the
- &title-refman-5-0;, available from the MySQL AB website.
-
-
-
For those wishing to take a look at the bleeding edge of MySQL
development, we make our BitKeeper repository for MySQL publicly
available. See .

Modified: trunk/refman-common/news-4.1.xml
===================================================================
--- trunk/refman-common/news-4.1.xml 2005-10-20 01:22:32 UTC (rev 116)
+++ trunk/refman-common/news-4.1.xml 2005-10-20 03:28:50 UTC (rev 117)
@@ -166,6 +166,20 @@



+
+
+
+ When executing single-table UPDATE or
+ DELETE queries containing an ORDER
+ BY ... LIMIT N clause,
+ but not having any WHERE clause, MySQL can
+ now take advantage of an index to read the first
+ N rows in the ordering specified in
+ the query. If an index is used, only the first
+ N records will be read, as opposed
+ to scanning the entire table. (Bug #12915)
+
+




Modified: trunk/refman-common/news-5.0.xml
===================================================================
--- trunk/refman-common/news-5.0.xml 2005-10-20 01:22:32 UTC (rev 116)
+++ trunk/refman-common/news-5.0.xml 2005-10-20 03:28:50 UTC (rev 117)
@@ -188,6 +188,20 @@
.


+
+
+
+ When executing single-table UPDATE or
+ DELETE queries containing an ORDER
+ BY ... LIMIT N clause,
+ but not having any WHERE clause, MySQL can
+ now take advantage of an index to read the first
+ N rows in the ordering specified in
+ the query. If an index is used, only the first
+ N records will be read, as opposed
+ to scanning the entire table. (Bug #12915)
+
+





--
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe: http://lists.mysql.com/internals?uns...ie.nctu.edu.tw