Slashdot Mirror
PostgreSQL Slammed by PHP Creator
leifbk writes "'The Web is broken and it's all your fault' says Rasmus Lerdorf, the creator of PHP. He talks about not trusting user input, and the brokenness of IE, which is all fine. Then he makes a statement about MySQL vs PostgreSQL: 'If you can fit your problem into what MySQL can handle it's very fast,' Lerdorf said. 'You can gain quite a bit of performance.' For the items that MySQL doesn't handle as well as PostgreSQL, Lerdorf noted that some features can be emulated in PHP itself, and you still end up with a net performance boost. Naturally, the PostgreSQL community is rather unimpressed. One of the more amusing replies: 'I wasn't able to find anything the article worth discussing. If you give up A, C, I, and D, of course you get better performance- just like you can get better performance from a wheel-less Yugo if you slide it down a luge track.'"
You are basing this on a rather incomplete account of my actual talk. I went through a series of optimizations of a sample Web application, and one of many steps was to try MySQL instead of PostgreSQL for that particular application. By profiling it with Callgrind it was obvious that in this particular case MySQL was significantly faster. I don't think this is news to anybody that MySQL is quicker at connecting and issueing simple queries, and I am not sure why me showing some Callgrind profiles and stating that MySQL is particular good at these things is frontpage slashdot material. Slow day?
And the "The Web is broken and it is all your fault" thing was just a bit of humour to wake people up for this 9am talk, but I guess it makes for good headlines.
I got sick of the syntax dialects of every SQL engine, so I started writing my applications using Hibernate and haven't looked back.
I learned HQL (Hibernate Query Language) and just use whatever database is handy at the time.
I usually start with MySQL 5, and then if I need more muscle (Read: the boss wants to spend money), I can switch the entire application to Oracle in about two hours.
You want ACID...? Use J2EE transactions and Hibernate, and never worry about which database you use again.
PHP/FI was the second version, and it wasn't written in Perl. Neither was the first version. The first version of PHP replaced some Perl code which may be where this myth comes from.
APC is broken in so many ways it is unbelievable.
eAccelerator however performs a thousand times better and actually works.
Ever new major php build makes noticeable efforts to break eAccelerator while making concessions to APC.
It is very frustrating. APC just plain sucks. eAcclerator rocks.
The feature you are talking about is vital to the proper operation of a real database. The "transactional reasons" you refer too are the difference between a "real" database and a toy like "mysql" (which is neither yours nor very good SQL) Imagine two operations concurrently operating on a database, one in the process of modifying the data, the other simply reading it. The first process starts a transaction and makes a lot of changes, then commits the changes. The second query just wants to execute a quick query. The second query gets its data and is done. When the first operation finishes, its changes become available. No one had to wait for anything. In MySQL, the second query would have to wait. As we see in so many MySQL web sites, as the waiters pile up, sooner or later you run out of MySQL connections and start to get error messages. IMHO, one of the reasons why the web is broken is that it is so easy to create content that no one takes the time to learn the basic computer science involved. When things break or perform poorly, they blame everyone but themselves. There is REAL science in computers, if if you ignore it, you'll never do anything worth while.
They do. And unfortunately I have direct experience with these people... and for the record, I *mostly* hate it.
Where I work, some of the architects and designers have decided to store more than a little XML in Oracle tables. In some cases this is not an entirely onerus decision (i.e. can make sense). e.g. if you are storing standardized configuration information in XML that will be queried as a string from the table and can be used by/passed to different consumer services/applications as an atomic unit (and which is not used in whole or in part as an sql 'where' predicate), then it can work.
However any time you may need to query information contained in the XML string, it seems to me to be kind of retarded to store it in a relational table. e.g. I have seen cases where IDs or service types etc. are stored in a large XML string in a field in a record, and eventually someone wants to retrieve a record based on that ID which is in the XML. This means parsing the field storing the XML in your query, killing any chances on performance since you are likely going to need a 'like' clause with wild cards at the front and back of the search term (even if the RDBMS has a built in XML search tool, the field still needs to be parsed). Unfortunately, people buy in to XML so much that some think that it is still OK to store XML in database tables... even in these cases.
I personally think it is generally a bad idea to store XML in a relational database as eventually the 2nd situation will come about (that is what experience tells me). You will then find that the practice totally negates the benefit of a relational database and sql (language) to easily and quickly retrieve relational data. I have seen this bite people many times. Ahhh... to use a technology, even a useful one, just because it is hip... but that is just my experience.
-- I ignore anonymous replies to my comments and postings.
And yet none of that explains why it is necessary for the original record to persist indefinitely.
It isn't "indefinitely," it is until vacuum is run, and yes, queries run while vaccum is operating.
Every database that has "multi-versioning" needs some sort of "purge" operation. It is all how and when it is executed.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
For the last 10 years, MySQL data has been atomic across single transactions.
For the last 5 years, MySQL data has been atomic across transactions.
For the last 2-3 years, MySQL has supported the full gammut of ACID features.
Can we PLEASE stop beating this particular dead horse?
The MySQL 5.0 FAQ
MySQL still lacks many of the high-level features of databases like Oracle, and for that many of us, the USERS of MySQL are generally greatful.
It does, but that's really a different matter.
Under MSSQL, there's no way of reading stuff from a table and not having the possibility of blocking something else or getting blocked. It's a trivial mistake to make, open the Enterprise Manager, load a big view or table and leave it open. The darn thing will keep a lock on the table unless you scroll down to the bottom of the result list.
You can use the WITH(NOLOCK) hint, but that's crap, as now you get uncommitted data in your SELECT.
Can we PLEASE stop beating this particular dead horse?
First off, the grandparent implied ACID was worthless. Not me.
When some idiot MySQL fanboy says ACID is worthless, I'm going to make sure anyone new to databases who reads the thread learns the truth.
Secondly, MySQL fanboys keep talking about how great it is at speed, and the only way modern MySQL is significantly faster than modern Postgres is when you use the non ACID compliant MyISAM. InnoDB and strict mode slow MySQL down so that it's no faster than Postgres or other 'real' relational databases. (With a real relattional database 'strict' isn't an option. It's a mandatory part of being a real relational database.) Plus with Postgres you get real modern high-level database features.
So to answer your question. NO. It's not dead yet.