Put back in comparison with PostgreSQL, design philosophy and features.

1 files changed, 360 insertions, 1 deletions

diff --git a/Docs/manual.texi b/Docs/manual.texi
index de71b9a6f4f..bba691d1e17 100644
--- a/Docs/manual.texi
+++ b/Docs/manual.texi
@@ -233,6 +233,7 @@ security bug in MySQL, you should send an e-mail to
 * MySQL Information Sources::   MySQL Information Sources
 * Compatibility::               How Standards-compatible Is MySQL?
 * TODO::                        MySQL and the future (The TODO)
+* Comparisons::                 How MySQL Compares to Other Open Source Databases
 @end menu
 
 
@@ -3634,7 +3635,7 @@ decimals.
 For platform-specific bugs, see the sections about compiling and porting.
 
 
-@node TODO,  , Compatibility, Introduction
+@node TODO, Comparisons, Compatibility, Introduction
 @section MySQL and The Future (The TODO)
 
 @cindex ToDo list for MySQL
@@ -4111,6 +4112,364 @@ Nothing;  We aim towards full ANSI 92 / ANSI 99 compliancy.
 @end itemize
 
 
+@node Comparisons,  , TODO, Introduction
+@section How MySQL Compares to Other Open Source Databases
+
+@cindex databases, MySQL vs. others
+@cindex comparisons, MySQL vs. others
+
+Our users have successfully run their own benchmarks against a number
+of @code{Open Source} and traditional database servers. We are aware of
+tests against @code{Oracle}, @code{DB/2}, @code{Microsoft SQL Server}
+and other commercial products. Due to legal reasons we are restricted
+from publishing some of those benchmarks in our reference manual.
+
+This section includes a comparison with @code{PostgreSQL} as it is
+also an Open Source database. If you have benchmark results that we
+can publish, please contact us at @email{benchmarks@@mysql.com}.
+
+For comparative lists of all supported functions and types as well
+as measured operational limits of many different database systems,
+see the @code{crash-me} web page at
+@uref{http://www.mysql.com/information/crash-me.php}.
+
+@menu
+* Compare PostgreSQL::          How MySQL Compares to PostgreSQL
+@end menu
+
+
+@node Compare PostgreSQL,  , Comparisons, Comparisons
+@subsection How MySQL Compares to PostgreSQL
+
+@cindex PostgreSQL vs. MySQL, overview
+
+When reading the following, please note that both products are continually
+evolving.  We at MySQL AB and the PostgreSQL developers are both working
+on making our respective database as good as possible, so we are both a 
+serious alternative to any commercial database.
+
+The following comparison is made by us at MySQL AB.  We have tried to be
+as accurate and fair as possible, but because while we know MySQL througly
+we don't have a full knowledge of all PostgreSQL features, so we may have
+got some things wrong.  We will however correct these when they come to our
+attention.
+
+We would first like to note that PostgreSQL and MySQL are both widely used
+products, but with different design goals, even if we are both striving
+towards ANSI SQL compliancy.  This means that for some applications MySQL
+is more suited, while for others PostgreSQL is more suited.  When choosing 
+which database to use, you should first check if the database's feature set
+satisfies your application.  If you need raw speed, MySQL is probably your
+best choice.  If you need some of the extra features that only PostgreSQL
+can offer, you should use @code{PostgreSQL}.
+
+@menu
+* MySQL-PostgreSQL goals::      MySQL and PostgreSQL development strategies
+* MySQL-PostgreSQL features::   Featurewise Comparison of MySQL and PostgreSQL
+@end menu
+
+
+@node MySQL-PostgreSQL goals, MySQL-PostgreSQL features, Compare PostgreSQL, Compare PostgreSQL
+@subsubsection MySQL and PostgreSQL development strategies
+
+@cindex PostgreSQL vs. MySQL, strategies
+When adding things to MySQL we take pride to do an optimal, definite
+solution.  The code should be so good that we shouldn't have any need to
+change it in the foreseeable future.  We also do not like to sacrifice
+speed for features but instead will do our utmost to find a solution
+that will give maximal throughput.  This means that development will take
+a little longer, but the end result will be well worth this.  This kind
+of development is only possible because all server code are checked by
+one of a few (currently two) persons before it's included in the
+MySQL server.
+
+We at MySQL AB believe in frequent releases to be able to push out new
+features quickly to our users.  Because of this we do a new small release
+about every three weeks, and a major branch every year.  All releases are
+throughly tested with our testing tools on a lot of different platforms.
+
+PostgreSQL is based on a kernel with lots of contributors. In this setup
+it makes sense to prioritise adding a lot of new features, instead of
+implementing them optimally, because one can always optimise things
+later if there arises a need for this.
+
+Another big difference between MySQL and PostgreSQL is that
+nearly all of the code in the MySQL server are coded by developers that
+are employed by MySQL AB and are still working on the server code. The
+exceptions are the transaction engines, and the regexp library.
+
+This is in sharp contrast to the PostgreSQL code where the majority of
+the code is coded by a big group of people with different backgrounds.
+It was only recently that the PostgreSQL developers announced that their
+current developer group had finally had time to take a look at all
+the code in the current PostgreSQL release.
+
+Both of the above development methods have their own merits and drawbacks.
+We here at MySQL AB think of course that our model is better because our
+model gives better code consistency, more optimal and reusable code, and
+in our opinion, fewer bugs.  Because we are the authors of the MySQL server
+code, we are better able to coordinate new features and releases.
+
+
+@node MySQL-PostgreSQL features,  , MySQL-PostgreSQL goals, Compare PostgreSQL
+@subsubsection Featurewise Comparison of MySQL and PostgreSQL
+
+@cindex PostgreSQL vs. MySQL, features
+
+On the crash-me page
+(@uref{http://www.mysql.com/information/crash-me.php})
+you can find a list of those database constructs and limits that
+one can detect automatically with a program.  Note however that a lot of
+the numerical limits may be changed with startup options for respective
+database.  The above web page is however extremely useful when you want to
+ensure that your applications works with many different databases or
+when you want to convert your application from one database to another.
+
+MySQL offers the following advantages over PostgreSQL:
+
+@itemize @bullet
+@item
+@code{MySQL} is generally much faster than PostgreSQL.
+
+@item
+MySQL has a much larger user base than PostgreSQL, therefore the
+code is more tested and has historically proven more stable than
+PostgreSQL.  MySQL is the much more used in production
+environments than PostgreSQL, mostly thanks to that MySQL AB,
+formerly TCX DataKonsult AB, has provided top quality commercial support
+for MySQL from the day it was released, whereas until recently
+PostgreSQL was unsupported.
+
+@item
+MySQL works better on Windows than PostgreSQL does.  MySQL runs as a
+native Windows application (a service on NT/Win2000/WinXP), while
+PostgreSQL is run under the @code{Cygwin} emulation.  We have heard
+that PostgreSQL is not yet that stable on Windows but we haven't
+been able to verify this ourselves.
+
+@item
+MySQL has more APIs to other languages and is supported by more
+existing programs than PostgreSQL.  @xref{Contrib}.
+
+@item
+MySQL works on 24/7 heavy duty systems.  In most circumstances
+you never have to run any cleanups on MySQL.  PostgreSQL doesn't
+yet support 24/7 systems because you have to run @code{VACUUM()}
+once in a while to reclaim space from @code{UPDATE} and @code{DELETE}
+commands and to perform statistics analyses that are critical to get
+good performance with PostgreSQL.  @code{VACUUM()} is also needed after
+adding a lot of new rows to a table.  On a busy system with lots of changes,
+@code{VACUUM()} must be run very frequently, in the worst cases even 
+many times a day.  During the @code{VACUUM()} run, which may take hours 
+if the database is big, the database is from a production standpoint,
+practically dead.  The PostgreSQL team has fixing this on their TODO,
+but we assume that this is not an easy thing to fix permanently.
+
+@item
+MySQL replication has been thoroughly tested, and is used by sites like:
+@itemize @minus
+@item Yahoo Finance (@uref{http://finance.yahoo.com/})
+@item Mobile.de (@uref{http://www.mobile.de/})
+@item Slashdot (@uref{http://www.slashdot.org/})
+@end itemize
+
+@item
+Included in the MySQL distribution are two different testing suites, 
+@file{mysql-test-run} and crash-me
+(@uref{http://www.mysql.com/information/crash-me.php}), as well
+as a benchmark suite.  The test system is actively updated with code to
+test each new feature and almost all reproduceable bugs that have come to
+our attention.  We test MySQL with these on a lot of platforms before
+every release.  These tests are more sophisticated than anything we have 
+seen from PostgreSQL, and they ensures that the MySQL is kept to a high
+standard.
+
+@item
+There are far more books in print about MySQL than about PostgreSQL.
+O'Reilly, SAMS, Que, and New Riders are all major publishers with books
+about MySQL.  All MySQL features are also documented in the MySQL on-line
+manual, because when a new feature is implemented, the MySQL developers 
+are required to document it before it's included in the source.
+
+@item
+MySQL supports more of the standard ODBC functions than @code{PostgreSQL}.
+
+@item
+MySQL has a much more sophisticated @code{ALTER TABLE}.
+
+@item
+MySQL has support for tables without transactions for applications that 
+need all speed they can get. The tables may be memory based, @code{HEAP}
+tables or disk based @code{MyISAM}.  @xref{Table types}.
+
+@item
+MySQL has support for two different table handlers that support
+transactions, @code{InnoDB} and @code{BerkeleyDB}.  Because every 
+transaction engine performs differently under different conditions, this 
+gives the application writer more options to find an optimal solution for
+his or her setup, if need be per individual table.  @xref{Table types}.
+
+@item
+@code{MERGE} tables gives you a unique way to instantly make a view over
+a set of identical tables and use these as one.  This is perfect for
+systems where you have log files that you order for example by month.
+@xref{MERGE}.
+
+@item
+The option to compress read-only tables, but still have direct access to
+the rows in the table, gives you better performance by minimising disk
+reads.  This is very useful when you are archiving things.
+@xref{myisampack}.
+
+@item
+MySQL has internal support for fulltext search. @xref{Fulltext Search}.
+
+@item
+You can access many databases from the same connection (depending of course
+on your privileges).
+
+@item
+MySQL is coded from the start to be multi-threaded while PostgreSQL uses
+processes.  Context switching and access to common storage areas is much 
+faster between threads than between separate processes, this gives MySQL
+a big speed advantage in multi-user applications and also makes it easier
+for MySQL to take full advantage of symmetric multiprocessor (SMP) systems.
+
+@item
+MySQL has a much more sophisticated privilege system than PostgreSQL.  
+While PostgreSQL only supports @code{INSERT}, @code{SELECT}, and
+@code{UPDATE/DELETE} grants per user on a database or a table, MySQL allows
+you to define a full set of different privileges on database, table and 
+column level.  MySQL also allows you to specify the privilege on host and 
+user combinations.  @xref{GRANT}.
+
+@item
+MySQL supports a compressed client/server protocol which improves 
+performance over slow links.
+
+@item
+MySQL employs a ``table handler'' concept, and is the only relational 
+database we know of built around this concept.  This allows different 
+low-level table types to be called from the SQL engine, and each table 
+type can be optimised for different performance characteristics.
+
+@item
+All MySQL table types (except @strong{InnoDB}) are implemented as files
+(one table per file), which makes it really easy to backup, move, delete
+and even symlink databases and tables, even when the server is down.
+
+@item
+Tools to repair and optimise @strong{MyISAM} tables (the most common
+MySQL table type).  A repair tool is only needed when a physical corruption
+of a data file happens, usually from a hardware failure.  It allows a 
+majority of the data to be recovered.
+
+@item
+Upgrading MySQL is painless.  When you are upgrading MySQL, you don't need
+to dump/restore your data, as you have to do with most PostgreSQL upgrades.
+@end itemize
+
+Drawbacks with MySQL compared to PostgreSQL:
+
+@itemize @bullet
+@item
+The transaction support in MySQL is not yet as well tested as PostgreSQL's
+system.
+
+@item
+Because MySQL uses threads, which are not yet flawless on many OSes, one
+must either use binaries from @uref{http://www.mysql.com/downloads/}, or
+carefully follow our instructions on
+@uref{http://www.mysql.com/doc/I/n/Installing_source.html} to get an
+optimal binary that works in all cases.
+
+@item
+Table locking, as used by the non-transactional @code{MyISAM} tables, is
+in many cases faster than page locks, row locks or versioning.  The
+drawback however is that if one doesn't take into account how table
+locks work, a single long-running query can block a table for updates
+for a long time. This can usually be avoided when designing the
+application.  If not, one can always switch the trouble table to use one
+of the transactional table types. @xref{Table locking}.
+
+@item
+With UDF (user defined functions) one can extend MySQL with both normal 
+SQL functions and aggregates, but this is not yet as easy or as flexible
+as in PostgreSQL.  @xref{Adding functions}.
+
+@item
+Updates that run over multiple tables is harder to do in MySQL.
+This will, however, be fixed in MySQL 4.0 with multi-table @code{UPDATE}
+and in MySQL 4.1 with subselects.
+In MySQL 4.0 one can use multi-table deletes to delete from many tables
+at the same time. @xref{DELETE}.
+@end itemize
+
+PostgreSQL currently offers the following advantages over MySQL:
+
+Note that because we know the MySQL road map, we have included in the
+following table the version when MySQL should support this feature.
+Unfortunately we couldn't do this for previous comparison, because we 
+don't know the PostgreSQL roadmap.
+
+@multitable @columnfractions .70 .30
+@item @strong{Feature}                     @tab @strong{MySQL version}
+@item Subselects                           @tab 4.1
+@item Foreign keys                         @tab 4.0 and 4.1
+@item Views                                @tab 4.2
+@item Stored procedures                    @tab 4.1
+@item Extensible type system               @tab Not planned
+@item Unions                               @tab 4.0
+@item Full join                            @tab 4.0 or 4.1
+@item Triggers                             @tab 4.1
+@item Constraints                          @tab 4.1
+@item Cursors                              @tab 4.1 or 4.2
+@item Extensible index types like R-trees  @tab R-trees are planned for 4.2
+@item Inherited tables                     @tab Not planned
+@end multitable
+
+Other reasons someone may consider for using PostgreSQL:
+
+@itemize @bullet
+@item
+Standard usage in PostgreSQL is closer to ANSI SQL in some cases.
+
+@item
+One can speed up PostgreSQL by coding things as stored procedures.
+
+@item
+For geographical data, R-TREES makes PostgreSQL better than MySQL.
+
+@item
+The PostgreSQL optimiser can do some optimisation that the current MySQL
+optimiser can't do.  Most notable is doing joins when you don't have the
+proper keys in place and doing a join where you are using different keys
+combined with OR.  The MySQL benchmark suite at
+@uref{http://www.mysql.com/information/benchmarks.html} shows you what
+kind of constructs you should watch out for when using different
+databases.
+
+@item
+PostgreSQL has a bigger team of developers that contribute to the server.
+@end itemize
+
+Drawbacks with PostgreSQL compared to MySQL:
+
+@itemize @bullet
+@item
+@code{VACUUM()} makes PostgreSQL hard to use in a 24/7 environment.
+
+@item
+Only transactional tables.
+
+@item
+Much slower @code{INSERT}, @code{DELETE}, and @code{UPDATE}.
+@end itemize
+
+For a complete list of drawbacks, you should also examine the first table
+in this section.
+
+
 @node Installing, Tutorial, Introduction, Top
 @chapter MySQL Installation