public inbox for [email protected]  

help / color / mirror / Atom feed

From: Chris Travers <[email protected]>
To: Alexey Borzov <[email protected]>
Cc: Tim Conrad <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Cc: PostgreSQL advocacy <[email protected]>
Subject: Re: [HACKERS] What can we learn from MySQL?
Date: Tue, 27 Apr 2004 20:48:38 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Alexey Borzov wrote:

> 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?
>
Maybe.  Just for jest-- If you read the Linux Coffee how-to, write a C 
module, get the right hardware, etc. Yes, PostgreSQL can make coffee!  
Of course, this would occur outside any sort of transactional control...

Seriously, though...  I think that it would be helpful to have a list of 
features which are under active development  (not just the ToDo list 
which are features which we want to develop).  We could also have 
contact info for leads (or maybe a contact via a web form, etc.) as well 
as status for that feature.  As the lead in a project whose roadmap has 
changed many times due to paid contracts, I don't really see the value 
of published roadmaps in general.

Best Wishes,
Chris Travers

view thread (145+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: [HACKERS] What can we learn from MySQL?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox