Received: from oberon.dnai.com (oberon.dnai.com [207.181.194.97]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id eBU1tIL57648 for ; Fri, 29 Dec 2000 20:55:19 -0500 (EST) (envelope-from kientzle@acm.org) Received: from neptune.dnai.com (neptune.dnai.com [207.181.194.93]) by oberon.dnai.com (8.9.3/8.9.3) with ESMTP id RAA43874 for ; Fri, 29 Dec 2000 17:55:18 -0800 (PST) Received: from acm.org (207-172-166-196.s196.tnt1.sfrn.ca.dialup.rcn.com [207.172.166.196]) by neptune.dnai.com (8.9.3/8.9.3) with ESMTP id RAA88405 for ; Fri, 29 Dec 2000 17:55:16 -0800 (PST) Message-ID: <3A4D404A.F4B4DE6E@acm.org> Date: Fri, 29 Dec 2000 17:54:18 -0800 From: Tim Kientzle Reply-To: kientzle@acm.org X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: PostgreSQL general mailing list Subject: Re: MySQL and PostgreSQL speed compare Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Archive-Number: 200012/831 X-Sequence-Number: 2116 > Search were almost the same ... sorting and > reading sorted entries from dba was the same. > But insert/modify/delete [ were up to 15 times > slower in PostgreSQL than MySQL ]. One of MySQL's big speed problems involves multi-user situations where some users are writing while others are reading; MySQL's table-level locking is a real drawback here, which is something your testing apparently did not exercise. (The new row-level locking code should alleviate this, but it's _very_ new and not something I'd want to risk in a production system today.) I've had several problems in the past with MySQL when one client would request a time-consuming DELETE (e.g., dropping several million rows containing last month's web log data). The DELETE could lock the table (and block most of the clients) for long periods of time (anywhere from 10 minutes to 1/2 hour for one system I implemented). In practice, of course, web applications are usually >99% reads, so this issue is often not a big problem. Nevertheless, if you're going to go with MySQL (which is a fine product), you should give some consideration to avoiding any time-consuming table modifications. (In the system I mentioned above, we moved the log data out of the database and into rotated log files on disk, which addressed the problem quite handily.) I also have some minor concerns about data integrity with MySQL's Berkeley DB tables, since I understand that the BDB tables store the row data within the B-Tree. This is fundamentally a less reliable design than other MySQL table types, which separate the data file from the index file. Index files are inherently more brittle, but easy to reconstruct if they get damaged. An almost purely theoretical quibble. More seriously, I'm also not certain whether MySQL's table-recovery utilities support BDB tables at all right now. This gives me pause. One big advantage of MySQL over PostgreSQL right now is ease of upgrading. Upgrading MySQL just requires shutting down the old one and starting the new; PostgreSQL requires a more involved process to migrate all of your data. (Of course, upgrading your DB is never a simple matter, but at least MySQL tries to make it less painful.) - Tim