X-Original-To: pgsql-advocacy-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id DB986D1B95E for ; Tue, 27 Apr 2004 14:52:12 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 94400-09 for ; Tue, 27 Apr 2004 14:52:11 -0300 (ADT) Received: from ngate.rdw.ru (mail.rdw.ru [195.42.172.4]) by svr1.postgresql.org (Postfix) with SMTP id D1446D1B52D for ; Tue, 27 Apr 2004 14:52:07 -0300 (ADT) Received: (qmail 5094 invoked from network); 27 Apr 2004 17:52:04 -0000 Received: from unknown (HELO rdw.ru) (192.168.0.57) by ngate.rdw.ru with SMTP; 27 Apr 2004 17:52:04 -0000 Received: (qmail 24924 invoked from network); 27 Apr 2004 17:52:04 -0000 Received: from ppp01.rdw.ru (HELO cs.msu.su) ([192.168.0.7]) (envelope-sender ) by rdw.ru (qmail-ldap-1.03) with SMTP for ; 27 Apr 2004 17:52:03 -0000 Message-ID: <408E9DC1.9030105@cs.msu.su> Date: Tue, 27 Apr 2004 21:52:01 +0400 From: Alexey Borzov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Tim Conrad Cc: PostgreSQL-development , PostgreSQL advocacy Subject: Re: [HACKERS] What can we learn from MySQL? References: <200404262213.44601.jm@poure.com> <200404262041.i3QKfZs28845@candle.pha.pa.us> <20040427152753.GA34713@external.timconrad.org> <408E825C.10209@cs.msu.su> <20040427160711.GA67934@external.timconrad.org> In-Reply-To: <20040427160711.GA67934@external.timconrad.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200404/264 X-Sequence-Number: 4236 Hi! Tim Conrad wrote: >>My favourite part of it is: >>-------- >>MySQL uses traditional row-level locking. PostgreSQL uses something >>called Multi Version Concurrency Control (MVCC) by default. MVCC is a >>little different from row-level locking in that transactions on the >>database are performed on a snapshot of the data and then serialized. >>New versions of PostgreSQL support standard row-level locking as an >>option, but MVCC is the preferred method. >>-------- > > Nice that you point out that incorrectly stated something. Even > nicer that you don't tell me what the correct answer would be. > Unfortunanatly, that's the best I could come up with with doing > research with the documentation I could find on the subject. MVCC > does a lot more than can be easily contained in a sentance. The problem is that in MySQL 1) MyISAM does table-level locking; 2) BDB does row-level locking; 3) InnoDB does MVCC (mostly) like PostgreSQL. PostgreSQL does support row-level locking (SELECT ... FOR UPDATE), table-level locking (LOCK TABLE ...), though this does not *replace* MVCC, as one may understand from the quotation. >>MySQL's roadmap is complete bullshit. Subselects were first promised in >>4.0, which was "not that far away" [1] back in 1998! Well, they are in >>4.1, which is still alpha in 2004. > > I realize this. I also realize that having a nicely defined roadmap would > give Postgres a hands up in this category. A hands up in *what* category? In bragging? Should PostgreSQL developers write something along the lines of "PostgreSQL 9i (available Really Soon Now) will also be able to make coffee"? Well, as you know about coffee now, why don't you add "make coffee" to your comparison table, with empty space in MySQL's and commercial DBMSs' columns and "in 9i" in PostgreSQL's one?