Differences between version 33 and predecessor to the previous major change of PostgresVsMysql.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 33 | Last edited on Thursday, January 12, 2006 6:22:35 pm | by ChristopherCashell | Revert |
| Older page: | version 32 | Last edited on Wednesday, December 14, 2005 10:27:29 am | by PhilMurray | Revert |
@@ -24,13 +24,13 @@
# Only __auto_increment__ is supported
# But it's spelled __INSERT INTO ... SELECT__ ("SELECT INTO" is actually a Sybase SQL extension, "INSERT INTO ... SELECT" is actually the SQL standard)
# Only with InnoDB tables
# Unless you use PostGIS which is a patch against PostgreSQL, but often lags behind the latest version
-# __Beware!__ As a result of MVCC, PostgreSQL cannot optimize a simple SELECT count(*) FROM table query. It will always use a sequential scan, this becomes very slow even on a table with only a few hundred thousand rows. This type of query is very
common in webapps, as a result you have to design your database and app around it. People often assume this type of query is free in terms of processing. In MySQL it is optimised away.
+# __Beware!__ As a result of MVCC, PostgreSQL cannot optimize a simple SELECT count(*) FROM table query. It will always use a sequential scan, this becomes very slow even on a table with only a few hundred thousand rows. This type of query is somewhat
common in webapps (though rarely necessary)
, as a result you have to design your database and app around it. Alternately, this can be emulated fairly trivially with a trigger that updates a counter on create/deletion of a new row
. People often assume this type of query is free in terms of processing. In MySQL it is optimised away.
# There are several projects out there with implement heavy modifications to PostgreSQL to implement replication, some rely on adding triggers to your database
-~UniForum posted studies that concluded that [MySQL] is slightly faster per query, but [PostgreSQL] can handle more concurrent connections. If you have that kind of load you really want to be looking at having redundancy and/or a bigger/better DataBase ([Oracle]?), though.
+~UniForum posted studies that concluded that [MySQL] is slightly faster per query, but [PostgreSQL] can handle more concurrent connections. If you have that kind of load you really want to be looking at having redundancy and/or a bigger/better DataBase ([Oracle]?), though (Although, PostgreSQL is robust enough to handle the .info and .org domain registry databases)
.
----
