Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

[Alexey Borzov]

Hi!
Tim Conrad wrote:
I was researching an article I wrote about a comparison between
Postgres and MySQL recently (If you want, you can read the article
at http://www.devx.com/dbzone/Article/20743/). I noticed some clear
differences between the mysql.com website and the Postgres website.
Sorry, couldn't resist: may I suggest doing the research *before* 
writing an article, not *after*?

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.


2) There doesn't seem to be a clear roadmap on Postgres features.
   When certian things are expected. There's the TODO list that
   Bruce maintains, but it only outlines 'near' fixes. MySQL has a
   nice listing of what to expect in certian future versions. I know
   it's not a perfect list, but it'd be nice to know when full blown
   replication will be included in PostgreSQL as an example.
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.

Of course, some gullible people actually believe this and compare [2] 
the existing and working implementations with vaporware (MySQL 5.1, 
anyone?).

   On those same lines, there doesn't seem to be anything about the
   improvements in the minor versions. It seems that in every
   release (i.e. 7.2,7.3,7.4) there are pretty significant changes,
   but finding a place that outlines these changes is somewhat
   difficult. 
Have you tried looking in the release notes [3]?
[1] http://www.geocrawler.com/archives/3/194/1998/8/0/1061364/
[2] http://www.devx.com/dbzone/Article/20743/1763?supportItem=1
[3] http://www.postgresql.org/docs/7.4/interactive/release.html
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
 joining column's datatypes do not match

Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?

[Alexey Borzov]

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?


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])