×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

First "Real" Benchmark for PostgreSQL

ScuttleMonkey posted more than 6 years ago | from the waiting-for-the-opportune-moment dept.

Databases 275

anticlimate writes "A new benchmark published on SPEC shows PostgreSQL's performance approaching that of Oracle's and surpassing or on par with MySQL (however the test-hardwares of the other DB systems are somewhat different). The test was put together by PostgreSQL's core developers working at Sun. They certainly are not unbiased, but this is the first 'real' benchmark with PostgreSQL — according to Josh Berkus's blog. The main difference compared to earlier benchmarks (and anecdotes) seems to be the tuning of PostgreSQL."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

275 comments

I do not think it means what you think it means. (5, Insightful)

Control Group (105494) | more than 6 years ago | (#19805251)

however the test-hardwares of the other DB systems are somewhat different

Which makes the results pretty much useless. But, being the intrepid slashdotter I am, I went ahead and R'ed the FA anyway, in case I could glean some useful information from it.

Which revealed that the linked article doesn't actually contain any information whatsoever about Oracle* or MySQL, much less benchmarks on named hardware.

So...what am I supposed to get out of this, again? Or is this just supposed to be some kind of PostgreSQL love-in, so I should take my wet blanket elsewhere?

*Well, the second link contains someone claiming that Oracle is only 15% faster...but without providing any actual data.

Mod parent way up! (2, Insightful)

khasim (1285) | more than 6 years ago | (#19805321)

You cannot compare benchmarks without SOMETHING standard between them.

Okay, if they can't match the hardware (why not?) then focus on price points. I notice that they're looking at "$65,500 for the hardware". That's a LOT of hardware at today's prices.

I'm sure MySQL would (and will) come back with a "benchmark" on hardware costing $10,000.

There is nothing "real" about this "benchmark".

Re:Mod parent way up! (2, Interesting)

Anonymous Coward | more than 6 years ago | (#19805539)

I can't speak for complex queries, but here are some simple findings from my testing:

Inserting 20 million rows, all simple inserts, only one primary key (int) with autoincrement for mysql and a sequence for postgres:
Avg Mysql time per 1000 inserts: 3 seconds
Avg Postgres time per 1000 inserts: 15 seconds (and gets worse over time)

That was after increasing the caches and disabling fsync on postgres too.

I also did a delete then insert for both (to flush out already existing rows), with similar results.

Ended up just inserting into a mysql table with no keys/indexes at all for maximum speed (average of .4 seconds per 1000 inserts), but didn't test that with postgres. Decided I only needed a static table anyway, so mysql was more ideal for it's speed in my situation. Sure with I had used postgres on a few more complicated projects though...

Posting AC to avoid flames.

Re:Mod parent way up! (5, Interesting)

Doctor Memory (6336) | more than 6 years ago | (#19806269)

Inserting 20 million rows, all simple inserts, only one primary key (int) with autoincrement for mysql and a sequence for postgres:
Avg Mysql time per 1000 inserts: 3 seconds
Avg Postgres time per 1000 inserts: 15 seconds (and gets worse over time)
OK, now do a seven-table join, including a self-join with a correlated subquery (MySQL does those now, right?). I think everybody knows by now that MySQL is pretty much untouchable as long as all you're doing is simple single-table stuff. Kind of like comparing a pickup truck to a moving van: if all you're doing is moving a couple of boxes around, then the pickup kicks. But when you need to move serious loads, then it's the pickup that gets to sit by the curb...

Re:Mod parent way up! (4, Insightful)

Vellmont (569020) | more than 6 years ago | (#19805679)


You cannot compare benchmarks without SOMETHING standard between them.

The thing that's standard is the benchmarking software.

If I were to buy a database server, do I really care which component of the solution is providing me with the great performance, or do I just want the performance? At the end of the day the only thing that really matters is the performance that comes out of the box.

It doesn't really matter if "Postgresql" is faster than "MySQL", because they always run on a certain physical computer. What matters is "I need to accomplish X,Y and Z. I have A dollars to spend. Which solutions accomplishes X, Y and Z the best within my budget? You can't separate the software from the hardware and get an answer that's very meaningful.

This benchmark isn't the last word on anything. Even a benchmark run on the exact same hardware means very little if you have a 2 core machine instead of 8.

Re:Mod parent way up! (1)

Control Group (105494) | more than 6 years ago | (#19805739)

You can't separate the software from the hardware and get an answer that's very meaningful

I take your point in general, but this statement is somewhat misleading. While you can't separate software from hardware entirely, you can be in a situation where you have a given supply of hardware, and need to know how best to use it - which amounts to much the same thing.

In that situation, knowing how each piece of software performs on a specific platform may be excellent information for you to have.

Re:Mod parent way up! (1)

Vellmont (569020) | more than 6 years ago | (#19805899)


you can be in a situation where you have a given supply of hardware, and need to know how best to use it - which amounts to much the same thing.

Sure, but you're talking about a specific piece of hardware. Sometimes you DO have a given hardware box and need to find software that works well on it. But how is a benchmark run on a totally different piece of hardware going to help you?

Benchmarks like these might give you kind of general ideas about the software, like "postgresql is in the same class as Oracle in terms of performance", but that's about it. It's a fuzzy answer, but in general I think that's all you're going to get from any Benchmark. I think that's what's really going on here, nothing more.

Solving real world problems are rarely as simple as the benchmarks. It's even tougher with something like a database where there's no standard intensive operations like Quake III, or lame mp3 encoder, or even gzip that people tend to care about.

Re:Mod parent way up! (1)

Actually, I do RTFA (1058596) | more than 6 years ago | (#19806179)

I notice that they're looking at "$65,500 for the hardware".

Yes, but they are comparing it to $74,000 for Oracle's hardware. The part that worried me is that "all benchmark runs were extensively optimized by the Sun performance team, with the help of performance experts from the databases represented." And they said they spent 6 months optimizing it. My goal is to find the sweet spot that combines: Money, Performance, and Development (and Code Maintance) costs. If it's possible to get great performance out of something by making the code hard to develop and maintain, that's worth a lot less to me.

Re:I do not think it means what you think it means (3, Insightful)

Ngarrang (1023425) | more than 6 years ago | (#19805363)

To paraphrase an old saying:

There are lies, damned lies and benchmarks.

Re:I do not think it means what you think it means (5, Informative)

KillerCow (213458) | more than 6 years ago | (#19805467)

I think that somebody sent the wrong link and (surprise!) the editors didn't even follow it to check.

Here's a more useful one: All SPEC jAppServer2004 Results Published by SPEC [spec.org]

The benchmarks aren't standardized enough for any useful comparison. The hardware and configurations vary in almost every one.

Re:I do not think it means what you think it means (2, Insightful)

PhrostyMcByte (589271) | more than 6 years ago | (#19805723)

If you want to setup a dedicated database server, you want to know what software with what hardware will run the fastest. So while the benchmarks may not be useful to people wanting to setup a small multi-purpose server, it can still be useful for some people.

Re:I do not think it means what you think it means (4, Insightful)

Ungrounded Lightning (62228) | more than 6 years ago | (#19805473)

however the test-hardwares of the other DB systems are somewhat different

Which makes the results pretty much useless.


Not necessarily.

It's essentially useless for separating out how much of the performance difference is the result of the software's design, implementation, and tuning versus how much is due to the platform differences.

But such tests CAN be used to examine the performance of competing ENTIRE SYSTEMS, to inform choices between them.

They say: "Oracle on does THIS well, PostgreSQL on can be tuned so it does THAT well on the same benchmark."

This lets administrators (presuming they have access to the hardware info) get a bang-for-the-buck comparison.

For the rest of us, the interesting point is that PostgreSQL, running on its team's idea of realistic hardware, can produce performance in the same ballpark as Oracle running on Oracle's choice of hardware.

(Whether the necessary remaining data (what are hardwares x and y? how was PostgreSQL tunde) is published now, later, or never, is a separate issue. B-) )

Re:I do not think it means what you think it means (1)

Ungrounded Lightning (62228) | more than 6 years ago | (#19805495)

That should have read:

They say: "Oracle on {hardware x} does THIS well, PostgreSQL on {hardware y} can be tuned so it does THAT well on the same benchmark."

Re:I do not think it means what you think it means (1)

Minwee (522556) | more than 6 years ago | (#19805625)

As I recall, Oracle's choice of hardware consists of a very large chequebook and a stamp with your signature on it.

Re:I do not think it means what you think it means (3, Insightful)

Control Group (105494) | more than 6 years ago | (#19805683)

Oh, I agree. A benchmark of whole systems can be just as (or more) useful as a benchmark of individual pieces of software, depending on what your goals are.

But what's been presented here isn't even that. Links #1 takes us to a SPEC benchmark of PostgreSQL. It doesn't provide any information about anything else; there isn't anything to compare the benchmark to. Link #2 provides an unreferenced statement about Oracle's marginally superior performance on much more expensive equipment.

So, perhaps, one can begin to draw conclusions about PostgreSQL vs Oracle in the contexts of full systems. But neither link #1 nor link #2 provide any information about MySQL (except the quote: "[t]his publication shows that a properly tuned PostgreSQL is not only as fast or faster than MySQL").

Really, my criticism isn't of the benchmark (the data are the data, after all) or of the blog (one expects a vested PostgreSQL interest to comment on such a benchmark), but of the blurb here that either a) draws totally unwarranted conclusions, or b) depends on information it doesn't bother sharing.

Re:I do not think it means what you think it means (1)

Weslee (1118943) | more than 6 years ago | (#19805897)

All the details were published.

From the link in the article you can find the results, or just look here [spec.org] .

Hardware, kernel changes, PostgreSQL configuration, etc.
Its all on that page.

Re:I do not think it means what you think it means (1)

Qzukk (229616) | more than 6 years ago | (#19806207)

(Whether the necessary remaining data (what are hardwares x and y? how was PostgreSQL tunde) is published now, later, or never, is a separate issue. B-) )
From the SPEC site [spec.org] , click on the "Disclosures" links to find out the hardware and software used for each part of the test. For instance, the postgres server ran on a SunFire T2000 with one 8 core (4 virtual threads per core) UltraSPARC T1 processor at 1.2GHz, 16GB of ram running 64-bit solaris 10, etc. The HTML Disclosure links to the "Disclosure Archive" which is a .jar with all of the configuration files used.

Re:I do not think it means what you think it means (0)

Anonymous Coward | more than 6 years ago | (#19805719)

"R'ed"
Why did you do that? It doesn't make any sense. Look there - I wrote "doesn't" - which means "does not"; that's called a contraction. What do you think R'ed means? The R in RTFA stands for Read; by adding 'ed onto the end were you saying you "Readed" the article? If so, are you Ralph Wiggum?

tags (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#19805261)

thisisareallyreallyreallyreallyreallyreallylongtag
OT, but I guess tagging is working like it used to now?

Re:tags (1)

CaseCrash (1120869) | more than 6 years ago | (#19805331)

Yeah, why the hell is this tag (and others like it) showing up today? It's not coming from jokes in the comments. So what's up with these useless tags?

Benchmarks are like skidmarks (0, Funny)

Anonymous Coward | more than 6 years ago | (#19805275)

They're all shitty.

on the playground... (-1, Troll)

teknopurge (199509) | more than 6 years ago | (#19805301)

boys use mysql

men use PostgreSQL,

and _____ use MSSQL.

flame on... =)

Re:on the playground... (1)

eneville (745111) | more than 6 years ago | (#19805329)

boys use mysql

men use PostgreSQL,

and _____ use MSSQL.

flame on... =)
flaming is ok... but stupid. and even more stupid is people who can code only for one db platform.

Re:on the playground... (1, Informative)

Anonymous Coward | more than 6 years ago | (#19805367)

and real DBA's use informix..

like BSD.. no it's not dead yet.

Re:on the playground... (1)

nytrokiss (1097437) | more than 6 years ago | (#19805375)

What about IBM's DB? I hear it has 30% of the market however i have never seen it in action!

Re:on the playground... (2, Informative)

Kalriath (849904) | more than 6 years ago | (#19805427)

DB2? It's only useable on large mainframes (big iron, so to speak) from what I understand. Generally speaking only the REALLY large shops would use it, so I wouldn't be surprised you'd never seen it - neither have I. We're a pretty big organisation where I work, and we have a mix of Oracle, MSSQL, and Sybase servers.

Re:on the playground... (0)

Anonymous Coward | more than 6 years ago | (#19805481)

Runs on Linux too...

Re:on the playground... (5, Informative)

morgan_greywolf (835522) | more than 6 years ago | (#19805571)

DB2? It's only useable on large mainframes (big iron, so to speak) from what I understand.


Um, no. DB2 [ibm.com] these days runs on most major UNIX variants (HP-UX, Solaris, AIX, IRIX, etc.), Linux and Windows. It's used quite often, in fact. Most Enovia/VPM installations use DB2 backends, for instance. Modern versions use XML along with regular relational database stores and are very, very up-to-date technology-wise. Very scalable.

Re:on the playground... (1)

dekemoose (699264) | more than 6 years ago | (#19805643)

At where I work we've got a number of clients running DB2 on x86 Linux platforms, as well as larger AIX platforms and of course the mainframe. Seems to have a lot of capabilities but is a bit more finicky than Oracle and MS SQL. It seems to like to dead lock unless the DBA has really made sure it is set up properly.

Re:on the playground... (1)

teknopurge (199509) | more than 6 years ago | (#19805659)

DB2 runs on distributed systems too - I'm using it on a project right now. It's not bad at all.

Re:on the playground... (1)

Kalriath (849904) | more than 6 years ago | (#19806005)

Ok, apparently I'm somewhat wrong there. I wasn't aware it ran nowadays on your regular desktop PCs with Linux. Though, I must admit I can't see it running very fast compared to software DESIGNED for that type of platform.

How exactly did that get modded informative if it's wrong?

Re:on the playground... (1)

kpharmer (452893) | more than 6 years ago | (#19806281)

> Though, I must admit I can't see it running very fast compared to software DESIGNED for that type of platform.

Actually, it's probably the fastest solution out there for heavy reporting/analytical workloads on windows, linux or unix. Not sure about teradata and informix - haven't looked at them in quite a while.

Teradata, informix and db2 were doing the 'beowulf' thing years before anyone on slashdot asked what a beowulf cluster of these would be like. So, you can easily distribute data across a hundred db2 server blades to get very fast response times over terabytes of data. This can be far faster at the high-ends than the typical oracle scenario of range partitioning on a 32-way smp. And oracle grid is more failover oriented than performance oriented, so that doesn't really compete either, last I looked.

I've built and managed very large databases on oracle, db2 and sql server in the last five years. Of them all, db2 on unix was the easiest to build and manage. It did take a little extra time - since some of the tools are a little finicky, but the manageability and performance was far better than with either oracle or sql server. And with very large data - far, far better than with mysql or postgresql.

Re:on the playground... (1)

cervo (626632) | more than 6 years ago | (#19806349)

Please mod parent down. DB2 is not only for mainframes. I worked at a place which used a bunch of DB2 boxes running AIX.

While DB2 does run on mainframes, it also runs on many other operating systems, including Linux.

http://www-306.ibm.com/software/data/db2/9/ [ibm.com]

As you can see, DB2 runs on at least Linux, Windows, and Solaris. It also runs on AIX, even though I didn't see it mentioned in a quick glance on the page. Please check your facts next time.

Re:on the playground... (5, Funny)

CaseCrash (1120869) | more than 6 years ago | (#19805401)

boys use mysql men use PostgreSQL, and _____ use MSSQL.
and people who like to collect a paycheck use MSSQL.

Re:on the playground... (2, Insightful)

Kalriath (849904) | more than 6 years ago | (#19805487)

I dunno, I kinda like MSSQL. Hell, I use it alongside MySQL servers for my own projects (that, and having support for multiple platforms in your product is kinda a good idea). Sure, it's got horrific licensing (nowhere near as bad as Oracle's, though) but other than that, it's pretty good and reliable. I get the impression that the core of it wasn't written by MS way back when, though. And it sure wasn't built by the Windows team.

Re:on the playground... (1, Informative)

Anonymous Coward | more than 6 years ago | (#19805587)

Intelligent people use SQLite (or Berkeley DB) for apps that don't require a heavyweight DBMS.

Databases are even being used in many situations that would be better addressed using flat files.

Re:on the playground... (2, Funny)

teknopurge (199509) | more than 6 years ago | (#19805721)

Intelligent people use SQLite (or Berkeley DB) for apps that don't require a heavyweight DBMS.

Databases are even being used in many situations that would be better addressed using flat files.
That kind of mainframe/JCL talk is not welcome here...

Re:on the playground... (2, Interesting)

Fozzyuw (950608) | more than 6 years ago | (#19806215)

Intelligent people use SQLite (or Berkeley DB) for apps that don't require a heavyweight DBMS.

Databases are even being used in many situations that would be better addressed using flat files.

Now there's a good point. Is there any good documentation out there on databasing on what is the best solution for what kind of problem? Particularly, I would like to see something between flat-files and DBMS and then between different DBMS.

Though, technically, I'm stuck between whatever our 'host' is giving us (currently PostgreSQL, but usually MySQL, and I dabbled with MSSQL when an intern for the Government), I'd like to know when it might be better to actually just store some stuff in a flat file or even use an XML DB (which one collage professor loved to talked about as a holy grail).

Outside of "Basic Database Theory and Generic SQL" books, a programming class on Databases (how to build tree structures and navigate them, etc), I've never really got any 411 on the benefits of using MSSQL, Oracal, MySQL, PostgreSQL, etc and I've never gotten the change to learn more about advanced database features such as stored procedures or functions or whatever they might be called and what they're good for.

Recommended books, anyone?

Cheers,
Fozzy

p.s. I work mostly with internet applications.

The best way to truly compare (3, Interesting)

CaptainPatent (1087643) | more than 6 years ago | (#19805325)

Because Sun systems will always be different from the x86 based cores that run MySQL and Oracle, I think the best way to compare such software would be by constructing servers of equal price and seeing how PostgreSQL fares. The true question on any business person's mind is "how much to implement?"

Re:The best way to truly compare (3, Interesting)

Doctor Memory (6336) | more than 6 years ago | (#19805499)

Sun systems will always be different from the x86 based cores that run MySQL and Oracle
Umm, wrong both ways. Oracle runs really well on Sun SPARC hardware (and I suspect MySQL at least runs), and Sun also makes x86-based servers (built with AMD's Opteron chips). It shouldn't be any trouble to benchmark all three on the same hardware.

Well, no technical trouble, anyway — I doubt Oracle would like to have its performance compared to two free-as-in-beer competitors. Even if it comes out on top, people will still be tempted to think "Jeez, with the money I save on Oracle licenses, I can buy a faster server and make up the speed difference"...

Good, but it can be improved. (5, Interesting)

khasim (1285) | more than 6 years ago | (#19805531)

Get people from each group, give them the requirements and 5 different dollar amounts.

Let each team setup their systems how ever they want at each price point. Some will go with clustered servers. Some will go a single monster server. They know their products best so they'll be the ones best suited to choosing the configuration.

Then run the benchmarks. And keep hammering on them until AFTER the next patch release.

Yeah, it might run fast, but still be a bitch to patch/upgrade.

At $5,000 you might find that a cluster of MySQL boxes beats everything.

At $10,000 maybe something else is best.

$25,000

$50,000

$100,000

etc.

And finally, break it. Break it bad. What happens when something goes wrong? Oracle might cost a lot, but if they can come through with your data they might just be worth it.

If nothing else, you'll get the "best practices" nicely demonstrated by each group. :)

Re:Good, but it can be improved. (5, Funny)

suv4x4 (956391) | more than 6 years ago | (#19806091)

Get people from each group, give them the requirements and 5 different dollar amounts.
Let each team setup their systems how ever they want at each price point. Some will go with clustered servers. Some will go a single monster server. They know their products best so they'll be the ones best suited to choosing the configuration.


We gave each team $10000 and told them to build the best hardware and db setup they can:

** PostgreSQL got a small IBM Blade quad machine redundant setup:
"We're relying on standard industry solutions and reliability."

** MySQL clustered 4 PlayStation3 machines and wasted the rest on booze and women:
"We're practical, plus we know what is money best spent on!".

** Oracle purchased a 1200 square foot datacenter and installed a megacluster of 8132 quad-Xeon 64GB RAM 4TB disk machines. With $10'000...?!
"We... uhmm... we hit a great bargain, guys! You wouldn't believe it, but it's true!"

Re:The best way to truly compare (1)

mooingyak (720677) | more than 6 years ago | (#19805553)

This is wrong on a whole bunch of levels:

1. Postgres runs on, among other things, linux, and windows.
2. SOLARIS runs on, among other things, x86.
3. MySQL and Oracle run on, among other things, Solaris on a Sparc.

There is a basis for identical comparisons. I've done it.

OTOH, you got this one right:

The true question on any business person's mind is "how much to implement?"

Re:The best way to truly compare (3, Informative)

jhines (82154) | more than 6 years ago | (#19805593)

If you read the details, while being Sun machines, they are Opteron based, so yeah they compare.

Re:The best way to truly compare (1, Informative)

Anonymous Coward | more than 6 years ago | (#19806081)

The JEE side used Opterons, the DB side used UltraSPARC: Sun Fire T2000 Server, 1 chip 8 cores 1.2GHz UltraSPARC T1.

Re:The best way to truly compare (1)

PCM2 (4486) | more than 6 years ago | (#19806369)

Wait ... you're saying MySQL and Oracle only run on x86? What rock have you crawled out from under?

Bad firehose! (5, Informative)

greg1104 (461138) | more than 6 years ago | (#19805377)

Why this emaciated post made it while mine didn't I'll never know...here's how I submitted this story:
 
The current version of PostgreSQL now has its first real benchmark [ittoolbox.com] , a SPECjAppServer2004 [spec.org] submission [spec.org] from Sun Microsystems. The results required substantial tuning [sun.com] of many performance-related PostgreSQL parameters, some of which are set to extremely low values in the default configuration — a known issue that contributes to why many untuned PostgreSQL installations appear sluggish compared to its rivals. The speed result is close but slightly faster than an earlier Sun submission using MySQL 5 [spec.org] (with enough hardware differences to make a direct comparison of those results unfair), and comes close to keeping up with Oracle on similarly priced hardware — but with a large software savings. Having a published result on the level playing field of an industry-standard benchmark like SPECjAppServer2004, with documentation on all the tuning required to reach that performance level, should make PostgreSQL an easier sell to corporate customers who are wary of adopting open-source applications for their critical databases.

Re:Bad firehose! (5, Insightful)

MrNaz (730548) | more than 6 years ago | (#19805443)

I like yours better. The Slashdot editors need to have their balls cut off if they think the post that beat your onto the front page is better. Feel free to mod me down any time for bitching about this, but seriously, this post is SO much better than the one that made it.

DUH! (4, Insightful)

Slashdot Parent (995749) | more than 6 years ago | (#19805785)

Why this emaciated post made it while mine didn't I'll never know.
Yours wasn't posted because it didn't contain enough flamebait.

Re:Bad firehose! (1)

MythMoth (73648) | more than 6 years ago | (#19805829)

The accepted version is preferable to my eyes.

No offense, but yours is too verbose. I want to read a submissions that reassures me that there is Good Stuff Here [link], not one that stands as a substitute for the original.

Re:Bad firehose! (1)

A nonymous Coward (7548) | more than 6 years ago | (#19805907)

Maybe yours was second. When they got the first one, it was good enough, no point in waiting for a better one that might not ever arrive.

What are the tuning parameters? (2, Interesting)

Anonymous Coward | more than 6 years ago | (#19805405)

For those of us who don't have dozens of hours to do the necessary research, can some postgresql gurus sum up some of the most significant tuning parameters so us mere mortals can see similar performance gains?

I realize that a large part of the answer is going be "it depends on application, your hardware, and you query types", but surely there must be some general tips that we can follow given various typical setups. MySQL, for example, ships with several different configuration files: One suitable for a small installation, one for a mid-sized installation, one for large installation, etc.

What tuning can someone do to tune postgresql's default (conservative) config file to make it perform better?

hardware (0, Offtopic)

Deadplant (212273) | more than 6 years ago | (#19805459)

The plural of hardware is hardware, not hardwares.
Does slashdot not have a "check spelling" feature on the submission page?

Re:hardware (0)

Anonymous Coward | more than 6 years ago | (#19805657)


  Mine seems to have a "spell checkings" button.

Re:hardware (1)

rainer_d (115765) | more than 6 years ago | (#19805987)

> The plural of hardware is hardware, not hardwares.
> Does slashdot not have a "check spelling" feature on the submission page?

You must be new here.

SQL sucks (0)

Anonymous Coward | more than 6 years ago | (#19805505)

SQLite and Postgres are current my choices. What I really want are language bindings that preserve the structures, syntax and semantics of the language I'm using without the performance penalty of abstraction layers.

Re:SQL sucks (0)

Anonymous Coward | more than 6 years ago | (#19805767)

What I really want are language bindings that preserve the structures, syntax and semantics of the language I'm using without the performance penalty of abstraction layers.

It's called programming. You should try it.

Re:SQL sucks (1)

mwanaheri (933794) | more than 6 years ago | (#19805769)

then you're a good candidate to use an object-database. However, I don't know yet how well they scale. Apart from that, managing concurrent transaction might be a pain. I'm playing with db4o in my next project. Interesting database, but I will restrict it to single-user mode.

Benchmarking Custom Versions (0)

Doc Ruby (173196) | more than 6 years ago | (#19805519)

Has anyone used the PostgreSQL open source to refactor the DB to support just a subset of SQL and features (the most popular stuff that eg. "LAMP" uses), then benchmarked it vs the default distro, to show higher performance?

For that matter, has anyone merged any open source Java server container with PostgreSQL for higher performance of that use case, in an integrated architecture without network and other overhead for messages, and more atomic transactions?

SQLite versus Postgres (0)

Anonymous Coward | more than 6 years ago | (#19805537)

SQLite is faster [sqlite.org] than Postgres for many types of workloads.

Re:SQLite versus Postgres (1)

Just Some Guy (3352) | more than 6 years ago | (#19805691)

Absolutely! Of course, they don't really live in the same solution space so it's equally true to say that PostgreSQL is much faster than SQLite for many workloads.

Re:SQLite versus Postgres (1)

malraid (592373) | more than 6 years ago | (#19806049)

Just try to hammer each database with 50 concurrent transactions to see which one scales better!!

Re:SQLite versus Postgres (1)

Ant P. (974313) | more than 6 years ago | (#19806147)

I started getting problems just rapidly F5ing a php script that used an SQLite DB. Can't say anything about PgSQL, because I couldn't figure out how to set that up.

We finally have PROOF (but not real proof) (3, Informative)

Pap22 (1054324) | more than 6 years ago | (#19805585)

This publication shows that a properly tuned PostgreSQL is not only as fast or faster than MySQL, but almost as fast as Oracle (since the hardware platforms are different, it's hard to compare directly). This is something we've been saying for the last 2 years, and now we can prove it.
Postgresql 8.2 on UltraSPARC T1 [spec.org]
MySQL 5 on AMD Opteron 285 [spec.org]

The UltraSPARC has 8 cores on 1 chip and 16GB of memory.
The Opteron has 4 cores and 8GB of memory.

The UltraSPARC should smoke it every time.

Re:We finally have PROOF (but not real proof) (1)

truth_revealed (593493) | more than 6 years ago | (#19805845)

Postgres scored 778 on a probably more expensive machine with twice the RAM of the MySQL machine which scored 720. You call an 8% improvement "smoking it"?

Re:We finally have PROOF (but not real proof) (0)

Anonymous Coward | more than 6 years ago | (#19805847)

My understanding is that running mysql on anything with more than 4 cores shows a performance drop, so i can't see why you'd want to use more...

Re:We finally have PROOF (but not real proof) (1)

dino2gnt (1072530) | more than 6 years ago | (#19805867)

Actually, depending on the amount of floating point work required, the UltraSPARC T1 may perform slower. They smoke on integer performance, but on floating point, they're noticeably slower than a comparable non-SPARC.

Re:We finally have PROOF (but not real proof) (1)

Ant P. (974313) | more than 6 years ago | (#19806023)

Sounds a lot like the advert in Microsoft's "Get The Facts" FUD that got pulled from magazines.

Bias (1)

suv4x4 (956391) | more than 6 years ago | (#19805605)

They certainly are not unbiased

I guess that's a deal breake right there, no?

The test was put together by PostgreSQL core developers at Sun. Didn't we agree earlier, when talking about Intel/AMD benchmarks, that vendor supplied tests are wildly inaccurate?

PostgreSQL should concentrate on more developer tools and better marketing. The "it's got a ton of features you don't need" on a cryptic site doesn't help its cause.

People use MySQL because there's a wide support and lots of dev tools for it, and because the kind of people going for MySQL needs to do simple selects and inserts most of the time.

Re:Bias (1)

pavera (320634) | more than 6 years ago | (#19805951)

I really don't understand this argument. I've used PostgreSQL and MySQL pretty much interchangeably for the last 7 years. I have never felt a lack of dev tools or documentation/help from postgresql. Maybe I'm just smarter than the average joe, but setting up and running postgresql is not that much more difficult than mysql.

For the features it provides I much prefer postgresql. sure, clustering is harder, but for the "easy" things that mysql is supposed to be good at, you don't need clustering either. Once you're getting into "Oh, I need 5 DB servers to handle this load" then you're talking about serious DBA work no matter what platform you're using. I'd rather by default have referential integrity. Sure MySQL has it now, but only if you get InnoDB working, which is at least as hard (I think harder) than getting a default PostgreSQL running.

What developer tools is postgresql missing? I have no problems creating, maintaining, editing, or viewing databases in PostgreSQL. There are drivers for every language I've ever used (java, python, ruby, c++, php), what exactly is missing? Why should they "market" they aren't like MySQL they don't have a commercial version for which they get paid.

Elephant (3, Funny)

suv4x4 (956391) | more than 6 years ago | (#19805633)

Won't you guys agree, "elephant" doesn't exactly communicate "fast and modern" very well.
"Dolphin" comes a bit closer.

Who's coming up with those logos?

Re:Elephant (0)

Anonymous Coward | more than 6 years ago | (#19805707)

SQLite is small and nimble, the others are all bloated pieces of shit.

Re:Elephant (1)

Doug Neal (195160) | more than 6 years ago | (#19806193)

SQLite is small and nimble, the others are all bloated pieces of shit.
SQLite isn't very nimble on even a 1.5GB database.

It's the shiznit for storing config data in small Linux appliances though :)

Re:Elephant (1)

afabbro (33948) | more than 6 years ago | (#19805745)

Elephant communicates "really long memory".

Which, of course, is what you want in a RDBMS.

Who's coming up with this education system?

Re:Elephant (1)

suv4x4 (956391) | more than 6 years ago | (#19805917)

Elephant communicates "really long memory".

Which, of course, is what you want in a RDBMS.
Who's coming up with this education system?

--

I'm not convinced.

Dolphins are way smarter than elephants: we'll need an elephant/dolphin benchmark.

I'll get some monkeys to setup one.

Re:Elephant (3, Insightful)

pavera (320634) | more than 6 years ago | (#19805797)

"Dolphin" also conveys "fun play thing" to me...

I'd prefer the elephant that never forgets.

performance isn't the issue (1, Interesting)

SEAL (88488) | more than 6 years ago | (#19805703)

Performance isn't what causes a lack of acceptance in the marketplace for PostgreSQL.

The problem is twofold:

MySQL, as others have pointed out, has better developer support and they know their target audience. They supply a fast, easy to use database for those who don't need a whole lot.

Oracle supplies an enterprise level database that MySQL doesn't aspire to. PostgreSQL doesn't know where to fit in.

Do a little investigation on setting up PostgreSQL with fault tolerance and replication and you'll quickly see why large corporations cough up money for Oracle. Performance is one aspect of the price tag, but it is certainly not the only factor.

Re:performance isn't the issue (1)

killjoe (766577) | more than 6 years ago | (#19805959)

Postgres should aim itself as a replacement for MSSQL server.

Re:performance isn't the issue (1)

dave562 (969951) | more than 6 years ago | (#19806365)

That will never happen. MSSQL server exists because of Visual Studio and the ease of creating programs that rely on it as a backend. Which leads one back to the argument that I've come across a few times in this topic... Postgres is lacking a good development environment.

Re:performance isn't the issue (4, Informative)

pavera (320634) | more than 6 years ago | (#19806065)

I've been using both MySQL and PostgreSQL for 7 years now... I've never felt a need for "developer support". Or if that phrase means "documentation + message boards" I've never felt a lack from postgresql. I also really don't get the PostgreSQL is hard to use argument. In every linux distro I've used in the last 7 years (redhat, centos, suse, fedora core, ubuntu) they are exactly the same... IE apt-get, yum, whatever, install postgresql-server/mysql-server. Then $startupscriptdir/postgresql start....

Do people really get that hung up on using postgres as the initial user instead of root?!? That is the ONLY difference that I can see.

Now I can agree that maybe postgresql doesn't really "target" an audience, but that is also because they are a true open source project. They don't have a commercial version. I really don't think Linus sits around saying "Ok, we need to add this feature so that more fortune 500's will adopt linux". Or "we need to add feature xyz so this will appeal to small businesses". MySQL has a "target" audience because they are selling something. If you aren't selling anything, by definition you don't have a target.

Re:performance isn't the issue (1)

SEAL (88488) | more than 6 years ago | (#19806159)

I also really don't get the PostgreSQL is hard to use argument.

Did you try installing it on Windows a couple years ago? :-)

One reason MySQL quickly gained popularity is that they provided a Windows version early on. It took a long time before PostgreSQL finally got around to building a Win32 version with an installer. (Regardless of my opinions of running a database on Windows... the userbase is still huge).

Re:performance isn't the issue (1)

pavera (320634) | more than 6 years ago | (#19806223)

Ok, well you've got me there... I've never run a DB server on windows, Oracle on Solaris, PostgreSQL and MySQL on linux...

Re:performance isn't the issue (1)

lakeland (218447) | more than 6 years ago | (#19806339)

Hi Pavera,

I'm in a similar situation except I use MySQL. Lets look at why.

1) Ease of use: MySQL has readline, and supports lazier SQL programming. It has loads of syntactic sugar that lets you write simple things in whatever way makes sense to you. Adding users, changing passwords, backing up... it is all _easy_. Of course, postgres can do everything MySQL can too, the question is which is easier.

2) Extensive developer community. We use python and the MySQL/python integration is great. We have a few UDFs that are home-grown but some of them were just downloaded off the net and installed. I'm sure you can find far more for MySQL than for Postgres.

There are some features in postgres that I really wish I had in MySQL: proper commit and rollback, nice/easy triggers rather than the crude enum. Support for R-trees with more than 2 dimensions (but then postgres' 3 dimensions is only a small improvement). Overall though, MySQL just seems to work where postgres can be made to work...

Re:performance isn't the issue (4, Insightful)

LurkerXXX (667952) | more than 6 years ago | (#19806157)

Actually I think PostgreSQL might have eaten a lot more of the MySQL market if they'd simply been faster to market with better admin tools and Windows support.

Lots of folks went with MySQL early because of those factors. They also then tended to write all their PHP, etc, applications to only talk to MySQL, thus making folks who might have preferred PostgreSQL use MySQL to run the app that they needed to run. Once that happens you are kind of in a Catch-22 place. Folks won't write the apps for PostgreSQL until it's used by a larger chunk of the market, but it won't take that large chunk because all the 'cool' apps were written MySQL only, so they have to run MySQL instead of PostgreSQL

Re:performance isn't the issue (0)

Anonymous Coward | more than 6 years ago | (#19806187)

All the postgres solutions (slony-I, slony-II, pgcluster, others?) are horrible to setup, and don't really allow for great high availability. If you're doing a ton of reads (and not so many writes) pgcluster is nice I guess. Also, recovering from an actual failure on all these can be very much hist and miss.

Lower end Oracle is cheap, but scaling up does get really expensive, but there isn't any "free" competition as you start scaling.

Re:performance isn't the issue (2, Insightful)

kpharmer (452893) | more than 6 years ago | (#19806201)

> MySQL, as others have pointed out, has better developer support and they know their target audience. They supply a fast,
> easy to use database for those who don't need a whole lot.
> Oracle supplies an enterprise level database that MySQL doesn't aspire to.
> PostgreSQL doesn't know where to fit in.

This is an oversimplification. Each vendor sees itself in all markets:
    - oracle/db2/sql server have free versions for tiny apps and very expensive versions for massive apps
    - mysql says it doesn't want to do what oracle does, but also says that this is less than 1% of the market - and knows that plenty of smallish databases are on oracle
    - postgresql like the others sees itself doing anything from very small databases to very large ones (often via Enterprise DB or other vendor extensions)

And using a single product for multiple sizes isn't illogical: if you have any very large databases (hundreds of gbytes or more) then you probably have a few dozen little ones as well. It's *far* easier to manage them all on oracle/db2/sql server - even with the small additional licensing costs - than to have a frankenstein collection of products to manage.

"Best tool for the job" is a good consideration when evaluating products (along with vendor viability, cost, etc, etc) - but once you've got a single tool in house to keep adding new products - each with their own licensing, support, patch, backup/recovery procedures, etc is a nightmare. Let alone actually federating your data - and having to test out how to virtualize or replicate data from oracle 10.x.x with mysql 5.y.y

> Performance is one aspect of the price tag, but it is certainly not the only factor.
Very true - and for that reason Postgresql has more going for it than many alternatives, like:
    - best licensing options - you don't need to pay a lawyer to go over your contract or license like you should if you use oracle or mysql commercially. And there's no fear that the vendor will change its license terms once you're locked in and start charging an arm and a leg.
    - very good foundation - postgesql isn't built from duct tape and bailing wire. The functionality within it is well tested and robust.
    - great support for standard database features - whether its subselects, stored procedures, triggers, etc - it's very simple to move from oracle to postgresql.
    - great ansi sql support - again, very standard sql - no unnecessarily propretary language elements.

So, yeah - just because Postgresql is performing well on some benchmarks that doesn't mean you should immediately throw out oracle in favor of postgresql. On the other hand, you also shouldn't discard it because it is a good general purpose database solution.

Re:performance isn't the issue (1)

SEAL (88488) | more than 6 years ago | (#19806263)

In case I sounded negative before: I have used postgres in several projects, both personal and professional. I think it is robust and stable, and I mostly agree with what you said.

Would I use it to handle a massively-multiplayer game, or a financial institution? No. Does it fit in for a lot of other projects. Yep.

- SEAL

Totally unbiased (0, Redundant)

Frosty Piss (770223) | more than 6 years ago | (#19805729)

The test was put together by PostgreSQL's core developers working at Sun.

No question of bias there...

MySQL 5 UltraSPARC T1 vs MySQL 5 Opteron (1)

Pap22 (1054324) | more than 6 years ago | (#19805879)

http://en.wikipedia.org/wiki/UltraSPARC_T1#_ref-0 [wikipedia.org]
Led me to...
http://blogs.digitar.com/media/2/T2000_Experience. pdf [digitar.com]

where a UltraSPARC T1 customer states that MySQL 5 is up to 13.5 times faster than MySQL 5 on an AMD Opteron.

The results of the original article's data were as follows:

Postresql 8.2 on UltraSPARC T1 - 778.14
MySLQ 5 on AMD Opteron - 720.56

So using my blatantly biased (yet at the same time factual) numbers, I correct the MySQL performance number to reflect what it would be on an UltraSPARC T1: 720.56 x 13.5 = 9727.56

9727.56 > 778.15

MySQL wins!

Which MySQL? (4, Interesting)

itsdapead (734413) | more than 6 years ago | (#19806183)

MySQL is modular - pick'n'mix data storage engines sharing a SQL front end. I can't find the bit in TFA that says which one they compared.

I've always suspected that most MySQL vs Postgres flame wars are based on comparing Postgres with the speed of MySQL/MyISAM (No transactions or relational integrity checks - so, big surprise, dead fast for simple queries) and then waving MySQL/InnoDB around when the functionality issue is raised.

MySQL/MyISAM hits the speed/functionality sweet spot for LAMP data-driven websites, is supported by lots of free webapp software and offered by most decent web hosting services. Comparing it speedwise with Postgres has always been pointless, though. If Postgres has caught up, colour me impressed, but if they're pro-Postgres I bet they're comparing with MySQL/InnoDB (which is a bit closer to like-with-like).

Never quite seen the point of MySQL/InnoDB really - all the advantages of MySQL/MyISAM minus the speed, support by popular webapps, availbility on low-cost hosts... and still lacks the features of Postgres.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...