@ned: "Has anyone spent any time with the MySQL 5.0 alpha, set to go into beta shortly (<url>
Would be interesting to have a rudimentary comparison checklist - not so much benchmarks, as features, as they seem to have added a lot.  And any info on how they've implemented these features (e.g. multiple table types in order to use different features, etc.) would be of interest.
Cheers,
Ned
-(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"
    @david: "<quote>
Anybody who's interested may want to check this:
<url>
There are 4 more links at the bottom of that page that will help.
Cheers,
D
David Fetter <email_address> <url>
phone: +1-951-888-1257   mobile: +1-951-888-1257
Remember to vote!
-(end of broadcast)-
TIP 6: Have you searched our list archives?
               <url>"
    @postgres: "For all those who think of comparing PostgreSQL - maybe this story 
should be added.
I HAD to do benchmark a benchmark comparing MySQL and Slony replication.
a. if you create a table as Innodb it MIGHT become ISAM without warning 
(depending on a nicely hidden config parameter).
b. it seems as if BEGIN / COMMIT are silently accepted in ISAM tables ...
c. when dumping a master database it will not necessarily restore on the 
slave database; we got a primary key violation on a unique
column a couple of times.
d. then we did a replication scenario:
lucent@schankserver:~/replication_tests/query$ cat 05.sql
BEGIN;
UPDATE t_one SET intvalue = id WHERE id = 'RANDOMINT';
UPDATE t_one SET intvalue = id WHERE id = 'RANDOMINT';
COMMIT;
BEGIN;
DELETE FROM t_one WHERE id = 'RANDOMINT';
ROLLBACK;
myisam -> innodb replication:
when doing this script above (30 concurrent users, 50 runs / user)
After the run PostgreSQL still had 500.000 records in the table - mysql 
had only 499.950 (rest was ignored because MyISAM cannot do rollback).
But if I do 30 user * 50 runs = 1500 delete statements; why do only 50 
records miss?
What do you think? Is a database allowed to eat data and issue as 
WARNING instead of a hyper-fatal error?
MySQL benchmark with replication; 2 concurrent users; 10000 repetitions
real 2m06.893s
MySQL benchmark with replication; 40 concurrent users; 500 repetitions
real 6m40.474s
In case of just two concurrent users MySQL is truly fast � it is very 
unlikely that two users will hit the same random data area. However, the 
situation changes dramatically when the number of concurrent users is 
risen. Although we execute the same number of statements MySQL will be 2 
� times slower (with Innodb). In case of MyISAM we have seen MySQL being 
5 times slower than PostgreSQL.
PostgreSQL with replication; 2 concurrent users; 10000 repetitions
real 2m4.317s
PostgreSQL with replication; 40 concurrent users; 500 repetitions
real 2m53.324s
In contrast to MySQL, PostgreSQL will perform really well in case of 
multiple concurrent users. The time needed is increasing but those 
changes are not that dramatical. We think that at least 10 seconds could 
be shaved off by doing further tweaks inside the background writer process.
Any more questions? Is it still worth to compare? I think we can agree 
that MySQL is crap ...
Best regards,
Hans
<quote>
-(end of broadcast)-
TIP 8: explain analyze is your friend"
    @chriskl: "That note about the lost replication rows should be added to the MySQL 
Gotchas site...
<quote>
-(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"
    @merlinmoncure: "<quote>
beta
(<url>
so
any
types
Putting my advocacy hat on,
If you look at their description of the upcoming features, it's
saturated with words like 'basic', 'initial', and 'rudimentary'.  I
don't think mysql 5.0 will be a watershed moment where it will become
the database of choice for industrial application development...
The new stuff on a point by point feature comparison may look
impressive, but they need to work on internal stuff like the locking
engine, get some real logging etc.
On a more even handed note, it's nice to see them get some real
features.  Open source success stories are not zero-sum, so what's good
for them is not necessarily bad for us.  Competition is good, but pg is
at least 3 years ahead of them in development!
Merlin
-(end of broadcast)-
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to <email_address>)"
    @robertbernier5: "Guys,
I sent an email to Hans-J�rgen Sch�nig <email_address> and asked if he 
could give me particulars about the bench marking he did. Could I have some 
comments about the idea of making a more structured presentation in an 
article, in the next SRA newsletter, <url> ?
<quote>
-(end of broadcast)-
TIP 7: don't forget to increase your free space map settings"
    @ned: "<quote>
That reminds me of another, related question ... can anyone comment on the relationship between MySQL 5 and MaxDB (formerly SAP DB)?  The talk at one point was that the end result of that alliance would be a total rewrite of MySQL to incorporate concepts from MaxDB, and that the new product would somehow be backward compatible with both predecessors.
-(end of broadcast)-
TIP 7: don't forget to increase your free space map settings"
    @robertbernier5: "Good point, but hard, solid, dependable information that is well presented is 
something you can't just ignore. I would like to go down this road a little 
farther and then look at the final product before deciding to publish or not.
<quote>
-(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"
    @josh: "Ned,
<quote>
That was the idea, yes.    Personally, I don't think it's possible; that's 
probably the reason why MySQL 5.0 is two years late.    I think eventually 
MySQL AB will have to come to terms with the idea that they have two seperate 
products, MySQL and MaxDB, and the two can't be made compatible.
Josh Berkus
Aglio Database Solutions
San Francisco
-(end of broadcast)-
TIP 6: Have you searched our list archives?
               <url>"
    @robertbernier5: "Thanks Hans,
What you've done is what everybody thinks of doing. When it's time, I'll 
review your posts to advocacy and depending on how it strikes me I can either 
write it up as part of a FAQ, an editorial or maybe a full blown how-to.
cheers
Robert
<quote>
-(end of broadcast)-
TIP 6: Have you searched our list archives?
               <url>"
    @postgres: "<quote>
We used PostgreSQL 8.0 RC3 and MySQL Debian packages (MySQL 4.0.22).
OS: Debian Linux on Amd Athlon.
	Best regards,
		Hans
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +1-951-888-1257
<url> <url>
-(end of broadcast)-
TIP 8: explain analyze is your friend"
    @postgres: "<quote>
Absolutely. I personally still hope that adopting MAX DB is their 
biggest fault.
Please take some time and look at the MAX DB sources - it is the most 
ugly thing I have ever seen in my live.
	Hans
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +1-951-888-1257
<url> <url>
-(end of broadcast)-
TIP 8: explain analyze is your friend"
    @markir: "<quote>
Might be worth re-doing with Mysql 5.0.2 - just in case they have fixed
the issues you found.
In addition use of a non production version of Pg and a production
version of Mysql in the comparison could be interpreted as a little loaded.
regards
Mark
-(end of broadcast)-
TIP 1: subscribe and unsubscribe commands go to <email_address>"
    @postgres: "<quote>
This was just a very brief test to get an impression.
A lot can be improved.
I did not want to use prepared statements because MySQL simply doesn't 
provide it. The idea is: If prepared statements are desired they should 
be put into the SQL files which are executed - the benchmarking software 
itself is a stupid as possible (it is not a JDBC benchmark; all it does 
is starting threads and executing any kind of SQL).
We decided to use the RC3 because 8.0 will be out shortly and we don't 
expect heavy changes anymore. So you can call this beta test.
While doing the test I got the impression that MySQL has bugs in their 
production system PostgreSQL doesn't even have in a random CVS checkout.
	Hans
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +1-951-888-1257
<url> <url>
-(end of broadcast)-
TIP 1: subscribe and unsubscribe commands go to <email_address>"
    @postgres: "<quote>
It is done by my benchmarking tool.
They do query based replication? Oh man, that really sucks ...
	Hans
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +1-951-888-1257
<url> <url>
-(end of broadcast)-
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to <email_address> so that your
      message can get through to the mailing list cleanly"
{'source': 'USENET', 'other_information': '{"reply_count": 14, "forum_name": "pgsql.advocacy.20140604.mbox"}', 'file': 'data/output/usenet-pgsql.advocacy.parquet'}