PostgreSQL - comments on Slashdot

I was very surprised to find that all the Slashdot comments, rated 4 and 5, were very positive and knowledgeable about PostgreSQL. I knew that PostgreSQL was better than MySQL in lots of ways, but I was surprised to find the extent of the weaknesses in MySQL.

The second comment I quoted from Slashdot, goes into detail about the commitment the PostgreSQL development team have towards maintaining and increasing the performance of PostgreSQL.

One of the other comments,m said that PostgreSQL version 8.2 was benchmarked at only 15% less than Oracle! So it would be interesting to do the same benchmark with PostgreSQL version 9.0, as this version is significantly faster.

http://developers.slashdot.org/story/10/09/20/2219254/PostgreSQL-90-Released
[...]
Re:Thank you! (Score:4, Informative)
by Anonymous Coward writes: on Tuesday September 21, @01:19PM (#33644378)

Thirded. There is absolutely no reason for anyone to be using MySQL any more other than the old silly excuse "my hosting provider doesn't have anything else". PostgreSQL is now faster than MySQL in all but the most trivial of contrived cases, doesn't require you to choose between table types for different load types, is just as easy to use and install, has all the features that MySQL has and runs on a Windows server (for those idiots who think that is a good thing). Also, the PG community is vastly more helpful and knowledgeable than the rabble that is the MySQL user base.

Finally, PostgreSQL is a proper independent open source project with a structure that all other open source projects should be judged by. MySQL has gone from hand to hand in the corporate world and has a future that is far from certain.
[...]
Re:As always... (Score:5, Interesting)
by greg1104 (461138) writes: Alter Relationship on Tuesday September 21, @03:27PM (#33645254) Homepage

You've got the performance part backwards for PostgreSQL; it goes up with every release, sometimes a little, sometimes in a big way. See PostgreSQL history [suckit.blog.hu] for a comparison covering versions 8.0 to 8.4. The mild regression in 8.4 shown there is actually reversible; it's mainly because a query related parameter for how many statistics to collect and use for query planning was increased by default. That results in better plans for most real-world queries, but it detuned this trivial benchmark a little bit. You can get performance back to 8.3 levels just by turning the parameter back to the "optimized for trivial queries" default of the older versions if you care about that. Most people prefer the new default. In the real world, 8.4 is actually faster due to improved handling of background VACUUM tasks too, which don't show up in simple benchmarks either.

I'm the current lead architect on building a PostgreSQL Performance Farm [2ndquadrant.com] to prevent regressions from popping into future versions of the code too. There is a recently completed beta client [github.com] for that purpose. We're in the process of working out how to integrate into future development, starting with 9.1, so that potential regressions are spotted on a commit by commit basis. I haven't seen any performance regressions between 8.4 and 9.0, only moderate improvements overall and large ones in specific areas that were accelerated.

Now, if you use some of the new replication features aggressively, that can add some overhead to slow down the master. But that's true of most solution; the data coming off the master has to take up some time to generate. The way PostgreSQL 9.0 does it is is pretty low overhead, it just ships the changed blocks around. Theoretically some statement based solutions might have lower overhead, but they usually come with concerns about non-determinism on the slaves when replayed (random numbers, timestamps, and sequence numbers are common examples).

Given the non-disclosure terms of most of the closed source databases, nobody can publish benchmarks that include them without going through something like the TPC or SPEC process. The last time that was done in 2007, PostgreSQL 8.2 was about 15% slower than Oracle [toolbox.com] running the same database-heavy workload. And note that it was PostgreSQL 8.3 that had one of the larger performance increases, so that was from just before a large leap forward in PostgreSQL performance.

At this point, Oracle and most other commercial databases still have a large lead on some of the queries run in the heavier TPC-H benchmarks. Links to more details as to why are on the PostgreSQL wiki [postgresql.org]. It just hasn't been a priority for development to accelerate all of the types of queries required to do well in that benchmark, and nobody so far has been willing to fund that or the subsequent certification via the TPC yet. Sun was the only one throwing money in that direction, and obviously the parts of that left within Oracle will no longer do so.
[...]