Very, very nice scaling performance under PGSQL is evident in the PDF, and I've no reason to assume the benches aren't legit. I think part fo the reason that PG was traditionally slower than MySQL was that it did lots of complicated locking to provide better scalability across processors, whereas we see MySQL performance dropping off after we go to more than eight cores. I think this was the same philosophy Sun took with "Slowaris", which was also far more scalabe than Linux at the time the moniker was in widespread use.
Still, I hope Linux can at least match this sort of superb scalability. CFS is fairly new, and I know there's optimisation work been done to it in.24 and.25, although it was a little sad to see the first iteration of CFS performing more poorly than its predecessor (and, if this is the case, I can see why Linus stonewalled CK's patches for so long, since they were mainly tested on desktop workloads). Are there any apples-to-apples comparisons out there that test various flavours and versions of Linux and BSD with a wide range of benchmarks? At the best review sites do a few benches with MySQL, and six months later everything has changed so it's incredibly difficult to do good performance comparisons.
Even so, it's refreshing to see precious little of the "BSD fudged their benchmarks!" trollspeak in the LKML thread, and plenty of talk about how to make Linux better. Open source is hippy capitalism - it also needs healthy competition to keep it in check:)
Offtopic: bug linked to in the LKML pointed me at this http://www.latencytop.org/ [latencytop.org] Sounds quite nifty
Very, very nice scaling performance under PGSQL is evident in the PDF, and I've no reason to assume the benches aren't legit.
Oh they are legit. The guy who did them has a thing for proper benchmark procedure and statistical analysis and is a physicist in real life.
He isn't an expert in MySQL and PostgreSQL but if he did underoptimize them, you can be assured he uderoptimized them in exactly the same way on both OS-es:)
Aye, I didn't expect they were - it's just a shock to see such a huge improvement almost overnight:D Development of the BSD's might appear glacial to those, like me, who are used to Linux, but it's refreshing to see that when they finally implement things they tend to get it very, very right.
I don't think that the FreeBSD guy fudged his benchmarks -- more likely, other FreeBSD people fudged the OS. Working with large-scale IRC servers, I have seen a few serious kernel-level race conditions on FreeBSD cause problems (like server processes that stop accepting connections in an unkillable state -- rebooting the server is a good way to fix things, right? -- and clients that appear to have the IP address 0.0.0.0). What's worse is that the unkillable process bug took many months to resolve. Linux
The "0.0.0.0 client address" bug was only present in the 7.0 development versions and was fixed prior to 7.0-RELEASE. If you are running IRC servers on unreleased OS code, you should expect problems.
I work in a total FreeBSD shop, and we've never seen the problems you've seen. Off the top of my head, we have FreeBSD deployed as firewalls in about 40 boxes, and probably that number in servers, too.
Of course, we're not running IRC--could these problems be systemic to that use?
No, they were both garden variety race conditions. This is single-threaded application code that doesn't do anything particularly novel or clever. IRC servers deal with new connections more often than most applications except high-traffic web servers, so the racy paths (in the system calls implementing accept() and getpeername() respectively) run a lot more often on large IRC servers than most places. To quantify "a lot", the server where the first problem was most troublesome sees upwards of 230 incomin
I think part fo the reason that PG was traditionally slower than MySQL was that it did lots of complicated locking to provide better scalability across processors, whereas we see MySQL performance dropping off after we go to more than eight cores.
Actually, what I remember is a bit different: Postgres supports transactions. MySQL's default MyISAM does not, and is thus faster.
Personally, I prefer correctness to speed -- and I also seem to remember that Postgres was always faster than MySQL's InnoDB.
Yeah, I've spent enough (down)time repairing MyISAM's to care about the supposed speed benefit any more - I'm a firm Postgres fan as well. On mine and others machines, the new 8.3 is blazingly fast, and there was a bench that I can't find any more that showed it trouncing MySQL for speed, and I've since ported all my little homebrew database thingies over to it. Shame that alot of apps only support MySQL (damn you, MythTV!).
Fortunately, at work, this isn't a problem, as we do everything in Rails. It's a small feature that I'm starting to see in more and more places -- the database is abstracted away.
Let me clarify: I just recently had to do a bit of restructuring of the corporate website. I developed and tested my changes locally on a sqlite database, then deployed to MySQL.
Which means that, as I'm also our admin, if I want to switch us over to Postgres, the app will be fine. It's the data I'd worry about...
Well, as someone who uses Pg with 100k unique user visits a day, Pg beats the crap out of Mysql if we're talking about anything else than very simple selects.
If you need transactions, stored procedures, subqueries, complex queries with joins, multi-value insert, etc., then you'll get much better performance results with Postgresql >= 8.2 than with Mysql. 8.3 adds a nuce performance gain on 8.2 aswell, while the database is much more consistent than mysql is.
Agree 100%. I've got to the stage where if I see something list MySQL support without Postgres support, I'm generally of the opinion they're not taking things seriously enough:) Postgres has been by DB of choice for about two years now, and I've yet to have it balls up on me, and speed has never been an issue - like you say, as soon as you start doing non-trivial stuff, Postgres utterly thrashes MySQL.
The closest to perfection a person ever comes is when he fills out a job
application form.
-- Stanley J. Randall
In short, wow (Score:5, Interesting)
Still, I hope Linux can at least match this sort of superb scalability. CFS is fairly new, and I know there's optimisation work been done to it in
Even so, it's refreshing to see precious little of the "BSD fudged their benchmarks!" trollspeak in the LKML thread, and plenty of talk about how to make Linux better. Open source is hippy capitalism - it also needs healthy competition to keep it in check
Offtopic: bug linked to in the LKML pointed me at this http://www.latencytop.org/ [latencytop.org] Sounds quite nifty
Re: (Score:2)
Oh they are legit. The guy who did them has a thing for proper benchmark procedure and statistical analysis and is a physicist in real life.
He isn't an expert in MySQL and PostgreSQL but if he did underoptimize them, you can be assured he uderoptimized them in exactly the same way on both OS-es :)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Of course, we're not running IRC--could these problems be systemic to that use?
Re: (Score:1)
Re: (Score:2)
Actually, what I remember is a bit different: Postgres supports transactions. MySQL's default MyISAM does not, and is thus faster.
Personally, I prefer correctness to speed -- and I also seem to remember that Postgres was always faster than MySQL's InnoDB.
Re: (Score:2)
Re: (Score:2)
Let me clarify: I just recently had to do a bit of restructuring of the corporate website. I developed and tested my changes locally on a sqlite database, then deployed to MySQL.
Which means that, as I'm also our admin, if I want to switch us over to Postgres, the app will be fine. It's the data I'd worry about...
Re: (Score:3, Informative)
If you need transactions, stored procedures, subqueries, complex queries with joins, multi-value insert, etc., then you'll get much better performance results with Postgresql >= 8.2 than with Mysql. 8.3 adds a nuce performance gain on 8.2 aswell, while the database is much more consistent than mysql is.
I think this boils down to the philosophy:
Re: (Score:3, Informative)