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.'"

Comments

wow

[aleksiel]

he's quite full of himself, isn't he?

the web is "broken" independant of the language used. bad/inexperienced developers are causing the problems, no matter what language is used. in order to not shoot yourself in the foot, you have to know that you're holding a gun and that pointing it at your foot and pulling the trigger are bad things to do.

and mysql and postgresql are different. they both have strengths and weaknesses. you can hammer in a screw faster than using a screwdriver, but thats not the friggin point of it.

Re:Considering the source

[PhrostyMcByte]

I'm sure you'll be modded to hell (who knows, maybe me too), but I agree with you entirely.

Take design advice from the people who brought us "magic quotes" and a configurability that makes it such a pain in the ass to write websites that will work the same on different servers? No thanks!

Re:There ARE other scriping languages besides PHP

[Billosaur]

I've been writing Perl for 6 years now and I've yet to find a more versatile language. I just started working in PHP, and it's Perl-like enough that learning it has been easy. But some things are just not done elegantly, and one has to wonder why that is, given that PHP is in fact pretty good as languages go.

Re:Avoid databases...

[Anonymous Coward]

PostgreSQL actually did used to be slower in most basic operations than MySQL. This was largely because MySQL used to lack some of the most basic things that make a DBMS relational (for example, for quite a long time there was no ACID compliance at all) whereas Postgres had them right from the start, but they weren't terribly efficient. As MySQL started trying to patch itself up into something a competent DBA wouldn't burst into flames over, PostgreSQL patched itself up to improve performance. The result was that they both basically got to the point where they were similar in features and performance.

The question you have to ask, I suppose, is this:

Would you prefer to have the patchwork system that made itself into a DBMS at some point after it's wide adoption, or the one that started out a relatively proper system and then just tweaked things to get performance gains?

I'm not going to begrudge the MySQL people their choice, but I'll stick with PostgreSQL and MS-SQL instead, thanks. I remember MySQL's orginal state, and my distrust for its ability and the competency with which it was initially built still runs pretty deep.

Regarding PHP: it's okay for moderate tasks and I use it, but I only use it because nobody else who's likely to maintain my code in the future seems to know any actual useful programming languages. If I thought I could trust future programmers to be reasonably competent with actual programming constructs (instead of just being trained to rely on the language to provide a function for every possibly thing you might need to do), I'd build everything in mod_perl with CGI::Application and a template framework instead.

And if you think I'm a database and language elitist, you might want to reconsider your position: am I an elitist, or are you (not the OP, you the reader) just poorly informed about the underlying concepts of these two things?

Where's the slam?

[Abu Hurayrah]

One performance enhancement that Lerdorf suggested based on code analysis was to use MySQL instead of PostgreSQL for the database. "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.

There's your "slam". Hardly a revelation, really. MySQL & PostgreSQL are two excellent databases that have different target audiences that overlap somewhat. I guess there are different kinds of extremists out there as well...

Postgres

[JustNiz]

OK here's something I never did understand about postgres:

If you modify a record in a postgres DB it keeps an invisible copy of the original for 'transactional reasons' and does not ever automatically delete it, even if there are no current transactional queries running. This means you can have a DB containing a single one field record and if you keep altering the field value you'll eventually run out of disk space. With any Postgres DB you therefore have to manually run a purge every now and again, and the purge slows the whole DB down to a crawl while its running (for us a purge had to be run every day otherwise the DB performance would be crazy slow, and the purge took over half an hour which during that time hardly any queries would run).

Basically, it just seems like Postgres has shot itself in the foot there.

I spoke to the developers and was told in a rather snooty reply that they had no plans to allow the user to optionally disable transactional 'features'.

Re:Rather incomplete quote

[Azarael]

:) Read his 2nd comment, above. You aren't emulating the behavior in your program, but letting one of php's db abstraction libraries handle it for you.

Re:Moo

[masklinn]

PHP is a nice product though, if anyone can get past its inconsistent function naming schemes.

And 3000 redundant functions, and absence of namespaces, and stupid syntax (does ANYONE know why PHP uses $prefixed names? I mean they make sense in Perl or Ruby because they have a meaning, but in PHP?), and the completely stupid misfeatures (register_globals or magic_quotes) which generate as many security holes (flash news: the web is mostly broken because of PHP), and retarded implementations of new features (yeah PHP finally having OO may be great, but Java's OO model just isn't fit for a dynamically weakly implicitely typed language)

Lerdorf is an idiot.

Re:He did *NOT* slam PostgreSQL

[Rasmus]

Exactly. But it makes a much more interesting /. story to take an imcomplete account of a talk and further mangle it.

Validating Input vs. Inexperienced Developers

[billstewart]

"You don't know that you have to filter user input," Lerdorf exclaimed.
Lerdorf advised PHP developers that nothing that comes across the wire is to be trusted.

It shouldn't be necessary to say that, but unfortunately it is. When I took Computer Science 100 in college 30+ years ago, the first lesson about inputting data was that you have to validate it before using it, because it's guaranteed that your program *will* be given bad data sometimes, and will occasionally be given maliciously bad data, and part of the grading process on programs was to run them on the professor's data set, which was malicious, especially at testing off-by-one errors and other boundary conditions. But enough other people didn't get that as part of their education, either in school or learning it the hard way in practice - sigh.

Re:Rather incomplete quote

[Rasmus]

That was a reference to the Expect header problem in Apache that was recently fixed and that not all the problems can be blamed on IE.

And yes, I do know my way around PostgreSQL. It's a good database, but no matter how you tweak it, it still has more connection overhead than MySQL does. And as I explained, I wasn't actually using the query cache in MySQL in the initial steps in this iterative optimization because MySQL's query cache doesn't kick in for prepare/execute queries. This isn't a PostgreSQL slam, it is simply pointing out that people should benchmark and profile their actual applications and understand the costs.

Re:Avoid databases...

[jalefkowit]

Amazingly this actually seems to be the approach lots of "Web 2.0" companies are taking. See Tim O'Reilly's database war stories series for details.

Some quotes from that series:

• Gabe Rivera of Memeorandum.com: "I didn't bother with databases because I didn't need the added complexity... I maintain the full text and metadata for thousands of articles and blog posts in core. Tech.memeorandum occupies about 600M of core. Not huge." [full story]
• Mark Fletcher of Bloglines: "[T]raditional database systems were not appropriate (or at least the best fit) for large parts of our system." [full story]
• Greg Linden of Findory: "We make thousands of random accesses to this read-only data on each page serve; Berkeley DB offers the performance necessary to be able to still serve our personalized pages rapidly under this load." [full story]

The "databases cause more problems than they solve" sentiment was so pronounced in O'Reilly's interviews that he took the question to Brian Aker of MySQL for rebuttal, but ended up concluding that

I didn't hear that flat files don't scale. What I heard is that some very big sites are saying that traditional databases don't scale, and that the evolution isn't from flat files to SQL databases, but from flat files to sophisticated custom file systems. Brian acknowledges that SQL vendors haven't solved the problem, but doesn't seem to think that anyone else has either.

Re:Who cares? use ORM.

[Richard W.M. Jones]

Who are these people who change databases all the time? We just figured that PostgreSQL was the best, it's free, we know how to use it and tune it, and so that's all we ever use. Now we can use all the wonderful SQL features of PostgreSQL and not worry.

A solution which forced us to regress to using Java or .Net is no solution at all BTW.

Rich.

Re:Avoid databases...

[DragonWriter]

Nah, you're just too insecure to admit that there are actually ways to rank the functionality of these things.

No, I've admitted that, several times, in this thread.

There are many ways to rank the functionality of things, not one correct way.

MySQL is good specifically in situations where you're going to do a lot of simple transactions on fairly simple data.

Which is, in fact, what a lot of web applications on LAMP infrastructure do.

That it's superior in that one, very narrow, situation, however, does not make it superior as an RDBMS

"Superior as an RDBMS" is mostly a meaningless, or at least equivocal and ambiguous, category.

or even equal to other software in the category.

Sure, in the sense that "different" is not "equal".

Likewise: PHP. PHP is an inferior programming language and that's that.

"Inferior programming language" is meaningless.

It's good at RAD and it has a very gentle learning curve.

And, in that, it is superior to languages that lack those features for uses where those are key features. Making it not unqualifiedly an "inferior programming language". Its like saying "A hammer is an inferior tool. It's good at driving nails, and that's it."

Perl is a better language. C is a better language yet.

There are certainly things for which C is better than Perl, and certainly there are things for which Perl is better than C. Your standard for saying that C is in some trascendent, unqualified sense "better...yet" compared to Perl is...what?

That PHP is good in one narrow field does not make it superior or even equal in its category.

True, again, because "superior" in the nonspecific sense you are using it is meaningless and, therefore, nothing could make anything superior in that sense.

It's really not that complicated of a concept.

It isn't a matter of complicated. It is a matter of wrong.

If you have two quarterbacks and one can throw the ball 75 yards consistently but can rarely get the ball anywhere near his receiver beyond five yards, he's very good at doing one particular thing, but he's still an inferior quarterback.

Really? If the other one can consistently hit a receiver out to 80 yards, but almost always fumbles the snap, I'm not sure if I could agree that the one you describe is "still an inferior quarterback": you can't label something inferior to something else when you describe the features of only one of the two things being compared. Further, the function of a quarterback on a football team is much more narrowly defined than that of a programming language or data storage solution, so it makes a lot more sense to talk about an inferior quarterback than an inferior programming language or datastore, without reference to a use for the latter.

Contrary to what some people would like to believe, not everything is equal just because it does certain things well that other products do on a more average scale.

I don't know what "some people" you are talking about, but I've never said "everything is equal". I would say that ranking tools without reference to application is generally meaningless except in the narrow case where the ranking holds without exception for all conceivable, or at least realistic, tasks.

Re:I love my Yugo luge commute

[nocomment]

I have. I built a 'Do Not Call' DB server to house 2 do not call lists for a telemarketer. A simple php interface. It searches through something like 10 million records in a fraction of a second. You don't even have your finger lifted off the mouse button and you already know the circumstances surrounding that phone number. Whether it's one they can call if a prior business relationship exists, if the number is free and open to annoy during dinner, or whether they cannot call under any circumstances whatsoever. The sucker flies. It's running on 900Mhz AMD Duron, 256M RAM, Generic IDE HD, running OpenBSD, and Postgresql.

Re:Slashdot

[Anonymous Coward]

Yes, slashdot uses MySQL. But a couple months ago, the entire site was down for 6 hours so they could add a new field to the comments table. When I added a new field to a Postgresql table (1.5 billion rows), it took 15 minutes, and the table was still usable while it was happening.

Since most everything you see is cached, it's more accurate to say they're using flat files.

Re:Rather incomplete quote

[SanityInAnarchy]

You are right, you were quoted out of context on at least a couple of things. And you probably had some insightful things to say, so I'm just going to use this as an excuse to rant:

What I find especially annoying is that it seems that the Web is more broken because of PHP than in spite of it. Valid to wake people up to a 9am talk -- when you're presenting Ruby to a PHP conference.

My own personal gripes are:

• While it's possible to call $self->method() from a method (or maybe that's $this->method?), if your function is called as a static class method, it has no way I've found of discovering what class it's in. Yet, you're forced to call static class methods as MyClass::Method. This defeats the main purpose of using a class as a namespace -- you still end up with your namespace referred to throughout the code, meaning you still have to use grep to change it, which can be unreliable.
• The syntax, in general, is clumsy at best. It basically feels more or less like any other C-like language. But this is web programming. I thought we were taking a speed hit to make things easier. I like Perl, Python, and Ruby for tons of syntactic sugar that PHP never had. preg_match is definitely clumsy when compared to =~.
• In order to access a global variable, I must have a line that says "global $variable". Forcing people to declare a variable is good, it means you'll probably notice your typos. If you're declaring a variable anyway, it saves a lot of typing, especially if you're using lots of tiny functions, to do this the Perl way -- say "my $variable" if you want it to be local, and just say "$variable" if you want it to check for a global one first.
• Prefixing every variable with a $ doesn't seem to serve any real purpose. Ok, so I can have a variable called $variable and a function called "function". I could do that anyway. It means you don't have to define variables to use them -- same with Ruby, except Ruby doesn't use prefixes. Perl uses prefixes, but it also uses them for interpolation in strings -- I don't think PHP can do that. Ruby manages that interpolation without prefixing variables except when they're in a string.
• Not a lot of scope choices. In fact, there seems to only be method scope and global scope, and maybe loop scope (foreach and friends), unless I'm missing something. What I miss is easy access to, say, class scope and object scope.
• A history of being seen as the easiest language for web programming, to where now many think "web backend programming" is always PHP, means you have lots of clueless newbie web programmers. The advantage of PHP was being easy to learn and having some nice features for web programming, but many of these (register_globals, anyone?) have been found to be security flaws, and are no longer reasons to use it. Yet, and I know this isn't your fault, given the choice between a PHP app and a Python|Perl|Ruby|C|ASP app, I won't choose PHP, because PHP developers tend to be the ones who say "If our app gives you security errors, just chmod 777..."

To be fair, I have found some advantages:

• Easy insertion of HTML code. This is nice for developing an app quickly. I still don't find it too incredibly useful in larger apps, though, because it makes more sense to split most of the HTML out into a separate file, and generate the rest, maybe even through some XML API.
• Powerful templates. Being able to embed real code into a mostly HTML template is a beautiful thing. And yet, I find myself both wishing it was a more powerful language, and thinking a better design (separating logic from presentation, using an existing template engine) would be better than what PHP offers.
• Good apps. As much as I hate the poorly-written PHP apps, I'm starting to work on Drupal... In this way, apps are a bit like game consoles, you get the one that plays the games you want. I think PHP attracting newbies probably leads to more decent web apps being written in PHP than in o