Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
how that can come, that table locking is faster than versioning? from how i understand versioning it can't be slower. and saying that possible access problems with table can be avoided be specially designing application. God! i must design specially for mysql, being locking whole tables. this page shows that they are low-end even in the mind. they didn't implemet constraints/subselects/views/triggers/full joins, but they've got packed bases and compressed client/server protocol! wow. must be cool. personally, when i tried 7.0.2, with triggers/constraints/views and other cool stuff (transactions!) i said to myself yep, that's the db you need. and now, whatever they say, when i hear somebody doing billing system (!) on mysql, i just shrug my shoulders. in russian it called everybody goes insane his own way. btw, what's related to in-memory quick db, what prevents you from creating memory filesystem and put postgres dbs there? in *bsd it's not a problem, on linux i believe too... On Sun, Aug 26, 2001 at 02:29:55PM +1000, Justin Clift wrote: We can always ask them to change things. The thing which strike me as Sean Chittenden wrote: Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Yeah, I've had a few developers show it to me... the best part -- Denis A. Doroshenko [GPRS engineer] .-._|_ | [Omnitel Ltd., T.Sevcenkos st. 25, Vilnius, Lithuania] | | _ _ _ .| _ | [Phone: +370 9863486 E-mail: [EMAIL PROTECTED]] |_|| | || |||(/_|_ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
yeah, by the way, doing dump/restore not such a bad thing, as mysql may say. supporting old stuff is sometimes horrible. look at micro$oft, which carries all the sh.t through its OSs... -- Denis A. Doroshenko [GPRS engineer] .-._|_ | [Omnitel Ltd., T.Sevcenkos st. 25, Vilnius, Lithuania] | | _ _ _ .| _ | [Phone: +370 9863486 E-mail: [EMAIL PROTECTED]] |_|| | || |||(/_|_ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
My favorite part of the artical was way way down at the end, where it briefly lists a few areas where postgres is still superior, minor little details such as full joins, sub-selects, views, unions, triggers, constraints, cursors... silly stuff like that :-) Glen ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
= In MySQL you have to repair your tables manually if corruption occurs. PostgreSQL is coded so that corruption cannot occur. Unless you're running pre-7.1, in which doing any of the following may corrupt an entire database so badly that pg_dumpall crashes on it. * Table A. Create mirror table B. Insert into B. Drop A. Rename B to A. Watch backend crash randomly, corrupting said table to unrecognizable form - hence corrupting entire database. This may only happen once every 1000 times the process is repeated, but *will* occur eventually. This happened more in 6.5. * Select, insert, update, whatever. Eventually, postgrees will report that the back end has exited unexpectedly. This is easier to repeat on an installation serving many simultaneous connections, especially if any database has been affected by: * Inserting any row with a total column length of 8k or higher, minus row/column overhead. For even more fun, insert a row of arbitrary length, or use multiple text columns. * Selecting, updating, or even remotely touching any table which has an example of the above. Yes, this means that you can't even delete the offending row, or pg_dump the database to remove it manually. What about pg_dump, you say? Sure, that'll work. Get the tables that aren't corrupted, like you know which ones they are. Then all you have to do is not give a rat's ass about the data in the table that *is* corrupted. Sounds easy, right? All of this vanished like smoke when 7.1 came out. In my opinion, 7.1 is the first real release of postgres, and hence Mysql is fully justified in most of its accusations/comparisons. Until 7.1, postgres didn't have a snowball's chance in hell at beating mysql on the stability front, now the odds are a little more even. Either way, don't dare sit there and tell me postgres doesn't corrupt tables. I would actually prefer a utility to integrity check/repair a corrupted table into something that the database could read, rather than give the data up for a loss and run for our backups, as we have been doing. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. ThomasINN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830| | Email: [EMAIL PROTECTED]AIM : trifthen | | Web : hamster.lee.net | | | | Most of our lives are about proving something, either to | | ourselves or to someone else. | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
WAL and Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
You guys shouldn't even be worrying about this. Five years from now, MySQL will be a much more mature product, but the way I see it now is this: MySQL: Great for message boards (Slashdot), information retrieval (an on-line phone directory that's mostly static), or other lightweight applications. PG7.1: Great for doing more commercial type things: inventories, accounting, and business in general, but it does lack some of the high-end DB features, particularly replication and clustering, and also some performance optimizations, which make it not quite in the big-leagues yet. Oracle: Great for everything beyond PG7.1. MS-SQL: Use this one if you desperately need Western currency and want to lose some plutonium! PG7.2: It finally has replication! This makes it a strong competitor to Oracle for most applications. Why is replication so important? If the data you are dealing with are valuable, you simply cannot trust them to one machine. Machines catch on fire, buildings burn down, earthquakes happen, lightning strikes. A disaster can happen any time, anywhere. The only solution to this is replication. Until PG has it, it can't be trusted with really valuable data. One thing which I would like to see in addition to replication is an enhanced WAL mechanism. Right now WAL only writes to a log file. That's fine, but I can see two other things that WAL could do very easily, which would be great for financial users, or others who deal with valuable data: One is sending the tuple, as a string, off to another server somewhere to be logged, perhaps in another DB of some kind. That way, when Server #1 gets struck by lightning, no problem, not a single transaction has been lost. This wouldn't take any major mods to the WAL system; if someone would tell me where to look in the code, I'll do it myself. The second WAL change would be to allow WAL to send output to a plain old dot matrix printer. Yes, it's a primitive thing to do, but again, if you are dealing with financial transactions, sometimes it's a wonderful thing to be able to have them in a human-readable read-only format. No amount of elite hacking can undo something which has been printed. This technique, as primitive as it sounds, is used all over the place. Ever notice that when you put your ATM card in the machine, you often hear a printer going? Everything is logged the old-fashioned way. Again, if someone will point me to the place in the WAL code where it has the tuple and it wants to write it out, I'll make these mods myself. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
Peter Eisentraut [EMAIL PROTECTED] writes: Justin Clift writes: If anyone else can see things blatantly wrong on that page, email me about them and I'll ask Monty (the MySQL guy) to please change/remove/fix them. http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Many of these advantages can easily interpreted as disadvantages. For example: * MySQL has more API to other languages and is supported by more programs than PostgreSQL. See section D Contributed Programs. = MySQL has 6 Perl modules, 5 ODBC drivers, and 4 C++ interfaces. PostgreSQL concentrates its efforts on making one driver work best for all users. For interfaces, it's best to have only one, and a good one (like one DBD module for perl, one JDBC interface for Java, one python module implementing the Python DB API (there are several Pg ones available here)). But this didn't just focus on APIs. * There are far moore books in print on MySQL than on PostgreSQL. O'Reilly, Sams, Que, and New Riders are all major publishers with books about MySQL. = MySQL is so hard to understand and poorly documented, a plethora of books had to come out before anyone could use it. That is a ridiculous claim. More documentation is good - like how to apply the different scenarios and by different authors. From Foo in 24 hours to Data mining with bar. * All MySQL features is also documented in the MySQL on-line manual because when a feature is implemented, the MySQL developers are required to document it before it's included in the source. = blah... :-) The MySQL documentation is actually rather nice (not saying that the PostgreSQL isn't). * MySQL has support for tables without transactions for applications that need all speed they can get. = MySQL is not a fully transactional database system. It defaults to this as well, AFAIR. * MySQL has internal support for text search. See section 6.8 MySQL Full-text Search. = PostgreSQL has a number of different full text search solutions available, or users can plug in their own. Weren't you the one preaching the wonders of one way to do it (API-wise) above? * You can access many databases from the same connection (depending of course on your privileges). = PostgreSQL does not allow you to access more than one database per connection. This makes the system much safer and allows for more robust design. Sometimes, you'd like to anyway ;) The person doing the bugzilla port would even like to have multi-DB operations (and split tables, with parts of the query running on each one). = PostgreSQL is coded from the start with multi-processing while MySQL uses threads. Threads have historically led to much more bug-prone programs and are poorly supported on many operating systems. If one thread crashes your whole server goes down. * MySQL has a much more sophisticated privilege system than PostgreSQL. = MySQL has a much more complicated privilege system than PostgreSQL. There is a difference between what must be done and what can be done. E.g. you can use Emacs quite comofortably as a very powerful editor without knowing much lisp. You can do anything you want if you need to. * MySQL employs the table handler concept and is the only relational database we know of built around this concept. = MySQL employs a table handler concept, which makes your code much less SQL compliant and makes MySQL harder to learn. Do you have to use it, or is it something you can choose to take advantage of? * Tools to repair and optimize MyISAM tables (the most common MySQL table type). = In MySQL you have to repair your tables manually if corruption occurs. PostgreSQL is coded so that corruption cannot occur. You sound like H.R. That's not a compliment. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
Me writes: http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Many of these advantages can easily interpreted as disadvantages. For example: I hope people aren't taking that feature comparison page as seriously as they took my parody of it. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
On Sun, 26 Aug 2001, Peter Eisentraut wrote: Many of these advantages can easily interpreted as disadvantages. For example: Have you ever considered a career in marketting? = In MySQL you have to repair your tables manually if corruption occurs. PostgreSQL is coded so that corruption cannot occur. Ho ho. This one is my favorite. -sam ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
Hi Sean, We can always ask them to change things. The thing which strike me as wrong the most is the stability issue with PostgreSQL. I've only very rarely heard reports by anyone saying MySQL was more stable than PostgreSQL for them. Most of the rest I think can be justified in one way or another. If anyone else can see things blatantly wrong on that page, email me about them and I'll ask Monty (the MySQL guy) to please change/remove/fix them. :-) Regards and best wishes, Justin Clift Sean Chittenden wrote: Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Yeah, I've had a few developers show it to me... the best part of this is though, when I tried to post a comment, I got a MySQL database error. ::grin:: At anyrate, it looks like a load of FUD from a bad marketing department (at least Microsoft lies well). -sc -- Sean Chittenden Part 1.2Type: application/pgp-signature ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
RE: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
We can always ask them to change things. The thing which strike me as wrong the most is the stability issue with PostgreSQL. I've only very rarely heard reports by anyone saying MySQL was more stable than PostgreSQL for them. Yeah, saying mysql is more stable than postgres is a complete joke from my own experiences and those around me. Also, I think people move from mysql to postgres, rarely the other way round.. - Andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: MySQL's (false?) claims... (was: Re: [GENERAL] PL/java?)
Sean Chittenden wrote: Has anyone seen this page on Mysql.org comparing PostgreSQL to MySQL: http://www.mysql.com/doc/M/y/MySQL-PostgreSQL_features.html Yeah, I've had a few developers show it to me... the best part of this is though, when I tried to post a comment, I got a MySQL database error. ::grin:: At anyrate, it looks like a load of FUD from a bad marketing department (at least Microsoft lies well). -sc One might also add as a 'con' for mysql...spelling. As horribly frequent the spelling errors are on this page, one might reasonable assume that you could... selected * frm tabloid wear valued be 'huh?'; -d -- : I may have the information you need and I may choose only HTML. It's up to you. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
