atomicity

Hugo Coolens <hugo.coolens@skynet.be> writes:

Is it true that the current version of PostgreSQL does always respect
atomicity of transactions and MySQL does not?

The former is true; the latter I don't know about (MySQL has recently
added "transactions" but I don't know any details about how they
actually work).

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863

Is it true that the current version of PostgreSQL does always respect
atomicity of transactions and MySQL does not?

MySQL only supports transactions on INNODB tables. Therefore if your
transactions includes other tables, we doubt atomicity works. Note this might
change with MySQL 4.1.

PostgreSQL offers the ability to build "intelligent" database with
server-side programming (PLperl, PLpgSQL, ..), triggers, rules, views,
operators... It is a real development tool.

In a complex environment, PostgreSQL can be optimized at ***software level***
(i.e. the way you build the database and program is server-side). MySQL can
only be optimized at ***OS level*** or ***Harware level***.

OS and Hardware level optimization can speed up an application by a factor of
2. Software optimization has no limit other than your imagination.

On the converse, MySQL is just an "dumb" database only running simple SQL
queries. Furthermore, it has very poor ODBC support and will only work in an
Apache environment.

If you are new to PostgreSQL, maybe the best thing to do is play with it
using pgAdmin2 GUI, which can be found at http://pgadmin.postgresql.org.

Best regards,
/Jean-Michel POURE

Good Day All,

On Wed, 2002-02-27 at 01:28, Jean-Michel POURE wrote:

Is it true that the current version of PostgreSQL does always respect
atomicity of transactions and MySQL does not?

The latest version of MySQL provides the option of supporting
ACID-compliant transactions and row-level locking

MySQL only supports transactions on INNODB tables. Therefore if your
transactions includes other tables, we doubt atomicity works. Note this might
change with MySQL 4.1.

MySQL supports transactions with InnoDB tables and DBD tables. Users
are provided with the choice of two different transactional table
types and two non-transactional table types - one file-based (MyISAM),
one memory-based (HEAP). The MySQL manual details this information.

Users can choose the table type that best suits their needs.

PostgreSQL offers the ability to build "intelligent" database with
server-side programming (PLperl, PLpgSQL, ..), triggers, rules, views,
operators... It is a real development tool.

I agree that PostgreSQL is a good development tool that has features
that MySQL does not yet possess (or that are more convenient to use in
PostgreSQL than MySQL).

I also believe that other databases, including MySQL are 'real'
development tools.

In a complex environment, PostgreSQL can be optimized at ***software level***
(i.e. the way you build the database and program is server-side). MySQL can
only be optimized at ***OS level*** or ***Harware level***.

OS and Hardware level optimization can speed up an application by a factor of
2. Software optimization has no limit other than your imagination.

This is an incorrect characterization of MySQL. Users have great
control over the behavior of queries and the behavior of databases.
These include options like delayed inserts, memory-stored indexes,
packed indexes for faster index reading, hash-based tables stored in
memory, read-efficient read-only databases, database replication, User
Defined Functions, etc.

On the converse, MySQL is just an "dumb" database only running simple SQL

MySQL has a large, well-tested feature set that includes fewer
traditional RDBMS features that PostgreSQL. PostgreSQL and MySQL come
from very different traditions. PostgreSQL is the heir to quite
phenonmenal amounts of academic research work that focused on
developing a complete set of RDBMS features. MySQL evolved from a set
of working development tools - it was developed with attention to
speed, stability and performance at the cost of certain features.

As PostgreSQL works to become a more practical development tool that
requires less maintenance and is more robust, MySQL works towards
having a larger set of features that are as robust as the current set.

queries. Furthermore, it has very poor ODBC support and will only work in an

To be specific, MySQL supports ODBC levels 0-3.51 - which is more than
PostgreSQL supported last time that I checked.

Apache environment.

This is incorrect. In addition to the source, we distribute binaries
for the following platforms:

- Linux
- Windows 95/98/NT/2000/XP
- Solaris
- FreeBSD
- MacOS X
- HP-UX
- AIX
- SGI Irix
- Dec OSF

If you are new to PostgreSQL, maybe the best thing to do is play with it
using pgAdmin2 GUI, which can be found at http://pgadmin.postgresql.org.

I would strongly consider reading Bruce Momjian's excellent book
(See http://www.ca.postgresql.org/docs/awbook.html)

--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Zak Greant <zak@mysql.com>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Advocate
/_/ /_/\_, /___/\___\_\___/ Calgary, Canada
<___/ www.mysql.com 403.244.7213

Le Mercredi 27 Février 2002 10:40, Zak Greant a écrit :

Good Day All,
Blablabla

Dear Zak,

MySQL is only good at one thing : marketing and propaganda.

Question : is your last mail a template? Was your previous mail generated
automatically? I already received dozens of such emails when trying to
unregister MySQL lists.

This does not work any more with me, sorry...

/JMP

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The latest version of MySQL provides the option of supporting
ACID-compliant transactions and row-level locking

Just to clarify, by "latest version", we are talking about the
MySQL 4.0 alpha release, correct?

Thanks,
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200202270853

-----BEGIN PGP SIGNATURE-----
Comment: http://www.turnstep.com/pgp.html

iD8DBQE8fOs1vJuQZxSWSsgRAumQAKCjyT+bvWbcJFiwZRCaon+T4INPZgCfbmIh
dqvKEdKcKfSdaubeLq3gkQk=
=PQxP
-----END PGP SIGNATURE-----

Hello Zak,

ZG> The latest version of MySQL provides the option of supporting
ZG> ACID-compliant transactions and row-level locking

ZG> MySQL supports transactions with InnoDB tables and DBD tables. Users
ZG> are provided with the choice of two different transactional table
ZG> types and two non-transactional table types - one file-based (MyISAM),
ZG> one memory-based (HEAP). The MySQL manual details this information.

MySQL's ridiculous way of handling transactions prompted us to
look at postgres, infact we incurred some amount of data loss as well.
MySQL was used for financials, and I was in real soup when I lost
the data.

As a matter of fact, MySQL didn't even recommend the use of
transactions in some of the documentation and if I am not wrong they
don't guarantee for the usage of Berkeley DB (from sleepycat) for
production environment. InnoDB is no big deal it is much
slower.

ZG> Users can choose the table type that best suits their needs.

Is this a plus point to use MySQL, i find it intriguing

ZG> I also believe that other databases, including MySQL are 'real'
ZG> development tools.

I still believe MySQL is best for websites and not for time-critical
financial applications. MySQL community support, i should say is
amazing.

ZG> MySQL has a large, well-tested feature set that includes fewer
ZG> traditional RDBMS features that PostgreSQL. PostgreSQL and MySQL come
ZG> from very different traditions. PostgreSQL is the heir to quite
ZG> phenonmenal amounts of academic research work that focused on
ZG> developing a complete set of RDBMS features. MySQL evolved from a set
ZG> of working development tools - it was developed with attention to
ZG> speed, stability and performance at the cost of certain features.

Atleast you acknowledge the fact that postgreSQL has evolved through
much more mature process than MySQL.

--
Best regards,
Gurudutt mailto:guru@indvalley.com

Life is not fair - get used to it.
Bill Gates

  I am taking this off-list -- no point in wasting everyone's time with
  this. I don't mind that you got in the parting shot in a public
  forum.:)

Do not hesitate to post this answer to a public forum.

  In the future, I would recommend that you provide hard facts to back
  up your opinions - if you do not, sensible people will discount your
  opinion as being uninformed.

Is MySQL able to run complex queries with 4-level nested LEFT and RIGHT
JOINS, perform complex actions using a database SERVER-SIDE language (Perl,
PLsql or whatever), run TRIGGERS to perform actions, REWRITE complex queries
using RULES, display VIEWS, altogether, come back to me and we will have a
beer.

Also, please note that your level 3 odbc driver does not work well. Do you
provide an enhanced GUI like pgAdmin2? This is not a question of technical
facts, PostgreSQL wins. Not a single serious programmer would trust MySQL for
all databases of a large company (I mean "all").

The problem is that you, at MySQL.com, are feeding the database user
community with:
- pre-written emails,
- pre-compiled marketing information (INNODB, "Transactions"),
- pre-written benchmarks sent to journalists (I noticed these were always the
same benchmarks...).

The main difference between "you" and "us" is that MySQL is a company and we
are a community. We don't whaste time sending marketing information...

Have a look at your homepage. This is not serious :

+ MySQL a winner in server database clash - 27 Feb 2002
In a recent database benchmark test performed by Ziff Davis Media Inc., the
company behind PC Magazine, eWeek and other well-known publications, MySQL
stands out as a winner.
= You sent them a benchmark and they published it. Tell me, how many people
are in charge of Journalists at MySQL (specialists, developpers, students,
how many?). At least the team who wrote this homepage. So, how many?

+ Letter from the CEO - 08 Feb 2002
= HaHaHa

+ Enhanced MySQL ODBC driver released - 31 Jan 2002
= Do you mean it never worked until 31 Jan 2002. I lost so much time with
your odbc crap.

+ U.S. Census Bureau Reaps Awards from MySQL-based Web Sites 14 Jan 2002
= Propaganda. Again, who wrote this article? Is it what you call an article?
Do you send pre-written articles to journalists?

+ Name the Dolphin has Ended - 10 Jan 2002
= Propaganda

+MySQL pushes Yahoo! into InfoWorld 100 list - 30 Nov 2001
= HaHaHa

+Leading European VCs Invest in MySQL AB - 12 Nov 2001
= And you really believe you can survive the PostgreSQL wave?

This is brain-wash my friend. So please brain-wash people on MySQL list, not
here, please.

Regards,
Jean-Michel POURE

Le Mercredi 27 Février 2002 17:07, Jean-Michel POURE a écrit :

Is MySQL able to run complex queries with 4-level nested LEFT and RIGHT
JOINS, perform complex actions using a database SERVER-SIDE language (Perl,
PLsql or whatever), run TRIGGERS to perform actions, REWRITE complex
queries using RULES, display VIEWS, altogether, come back to me and we will
have a beer.

Sorry I forgot something: MySQL adds ridiculous transactional support.

ZG> MySQL has a large, well-tested feature set that includes fewer
ZG> traditional RDBMS features that PostgreSQL. PostgreSQL and MySQL come
ZG> from very different traditions. PostgreSQL is the heir to quite
ZG> phenonmenal amounts of academic research work that focused on
ZG> developing a complete set of RDBMS features. MySQL evolved from a set
ZG> of working development tools - it was developed with attention to
ZG> speed, stability and performance at the cost of certain features.

MySQL surely employs a team of communication specialists. This kind of
argument can only be invented by a non-technician, non-programmer, non-RDBMS,
"marketing" someone. All this reminds me of my MBA.

MySQL AG employs a REAL team of FAKE communication specialists
whose goal is to sell a FAKE product to a team of FAKE investors,
who in turn will resell this FAKE company to a team of REAL people
who in turn will loose their REAL money. And cry...

/JMP