Thread: IBM/DB2 PostgreSQL FUD?
Last week, I got some DB2 literature from IBM. (I didn't ask for it, all I wanted was a CD with the software, but I guess they saw fit to send me the whole thing.) In this literature was a guide titled, "Why DB2 vs. Open Source Databases Sales Guide". The guide mostly concentrated on MySQL, but they did have one paragraph about PostgreSQL. They noted that SourceForge started off using PostgreSQL, but when the site grew it "crashed 4 to 5 times per day" under the increased workload as more people put their projects on SF. They of course then went on to praise how DB2 handles heavy workloads. Can anyone provide details on this? Were the servers misconfigured? I've run into situations where the postgres server will stop responding if the disk fills to capacity. We should prepare something to respond to this. Thanks, --Josh
> Last week, I got some DB2 literature from IBM. (I didn't ask for it, all > I wanted was a CD with the software, but I guess they saw fit to send me > the whole thing.) In this literature was a guide titled, "Why DB2 vs. > Open Source Databases Sales Guide". > > The guide mostly concentrated on MySQL, but they did have one paragraph > about PostgreSQL. They noted that SourceForge started off using > PostgreSQL, but when the site grew it "crashed 4 to 5 times per day" under > the increased workload as more people put their projects on SF. They of > course then went on to praise how DB2 handles heavy workloads. > > Can anyone provide details on this? Were the servers misconfigured? I've > run into situations where the postgres server will stop responding if the > disk fills to capacity. We should prepare something to respond to this. Off the top of my head they are quoting the article from Tim Perdue comparing mysql and postgres (google: mysql postgresql comparioson). The version was some 7.0.x version. They neglected to summarize his follow-up which was a big win for pg. However, it's from a non biased source, and is well documented. I agree that a rebuttal should be ready at will. Merlin
> > Can anyone provide details on this? Were the servers misconfigured? I've > run into situations where the postgres server will stop responding if the > disk fills to capacity. We should prepare something to respond to this. > They were running 7.1 at the time. I doubt this would be a problem now. Sincerely, Joshua D. Drake > Thanks, > --Josh > > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Attachment
On Mon, 12 Jul 2004, Joshua D. Drake wrote: >> >> Can anyone provide details on this? Were the servers misconfigured? I've >> run into situations where the postgres server will stop responding if the >> disk fills to capacity. We should prepare something to respond to this. >> > > They were running 7.1 at the time. I doubt this would be a problem now. If it was a problem then, they didn't let anyone know about it ... to the best of my knowledge, the move to IBM/DB2 was an infusion of cash (ie. bribe) from IBM, it wasn't anything technical ... but, again, I'd never heard of any technical problems with the servers *shrug* ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
On Mon, 2004-07-12 at 17:07, Merlin Moncure wrote:
>
> > Last week, I got some DB2 literature from IBM. (I didn't ask for it,
> all
> > I wanted was a CD with the software, but I guess they saw fit to send
> me
> > the whole thing.) In this literature was a guide titled, "Why DB2 vs.
> > Open Source Databases Sales Guide".
> >
> > The guide mostly concentrated on MySQL, but they did have one
> paragraph
> > about PostgreSQL. They noted that SourceForge started off using
> > PostgreSQL, but when the site grew it "crashed 4 to 5 times per day"
> under
> > the increased workload as more people put their projects on SF. They
> of
> > course then went on to praise how DB2 handles heavy workloads.
> >
> > Can anyone provide details on this? Were the servers misconfigured?
> I've
> > run into situations where the postgres server will stop responding if
> the
> > disk fills to capacity. We should prepare something to respond to
> this.
>
> Off the top of my head they are quoting the article from Tim Perdue
> comparing mysql and postgres (google: mysql postgresql comparioson).
> The version was some 7.0.x version. They neglected to summarize his
> follow-up which was a big win for pg. However, it's from a non biased
> source, and is well documented. I agree that a rebuttal should be ready
> at will.
>
A better rebuttal would be the shareholders information given out at the
time to VA stock holders that showed the agreement where IBM would
invest in VA and VA would switch to DB2. Course that's probably private
corporate information that can't be shared.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
People: > > Can anyone provide details on this? Were the servers misconfigured? > I've > > run into situations where the postgres server will stop responding if > the > > disk fills to capacity. We should prepare something to respond to > this. I'm also pretty sure that they laid off their PostgreSQL support staff *before* the switchover to DB2; as you can imagine, they ran into some problems in the interval. Merlin, if you can actually provide a link, I'm sure that Tim P. would be happy to give us a statement refuting IBM's interpretation. -- -Josh Berkus Aglio Database Solutions San Francisco
Robert, > A better rebuttal would be the shareholders information given out at the > time to VA stock holders that showed the agreement where IBM would > invest in VA and VA would switch to DB2. Course that's probably private > corporate information that can't be shared. Oh, you won't get that. But you can very well get a coincidence of timing from the IBM investment and the date of the switchover. Just google the news. -- -Josh Berkus Aglio Database Solutions San Francisco
On Mon, 2004-07-12 at 15:30, Joshua Kramer wrote: > Last week, I got some DB2 literature from IBM. (I didn't ask for it, all > I wanted was a CD with the software, but I guess they saw fit to send me > the whole thing.) In this literature was a guide titled, "Why DB2 vs. > Open Source Databases Sales Guide". > > The guide mostly concentrated on MySQL, but they did have one paragraph > about PostgreSQL. They noted that SourceForge started off using > PostgreSQL, but when the site grew it "crashed 4 to 5 times per day" under > the increased workload as more people put their projects on SF. They of > course then went on to praise how DB2 handles heavy workloads. This is horse puckies. Source Forge ran wonderfully on PostgreSQL, and I can remember when they switched to DB2, it took them over 6 months just to get keyword searching to work properly. And it was always VERY slow compared to how fast it had been on PostgreSQL. Find and ask the guy who built it originally, Tim Perdue. I'm pretty sure he'll back me up, unless he's under some kind of NDA to not say. > Can anyone provide details on this? Were the servers misconfigured? I've > run into situations where the postgres server will stop responding if the > disk fills to capacity. We should prepare something to respond to this. (I never experienced any downtime on sourceforge when it was running on PostgreSQL, and haven't ever heard crashing as the reason it was converted to DB2, only that IBM was partnering with them and offered it for "free" (i.e. they paid them to use it.)
On Mon, 2004-07-12 at 22:30, Joshua Kramer wrote: > Last week, I got some DB2 literature from IBM. (I didn't ask for it, all > I wanted was a CD with the software, but I guess they saw fit to send me > the whole thing.) In this literature was a guide titled, "Why DB2 vs. > Open Source Databases Sales Guide". > > The guide mostly concentrated on MySQL, but they did have one paragraph > about PostgreSQL. They noted that SourceForge started off using > PostgreSQL, but when the site grew it "crashed 4 to 5 times per day" under > the increased workload as more people put their projects on SF. They of > course then went on to praise how DB2 handles heavy workloads. This little gem from last year explains how DB2 handles heavy workloads: http://www.danskebank.com/link/ITreport20030403uk/$file/ITreport20030403uk.pdf though doesn't mention DB2's pessimistic locking strategies which can lead to poor database concurrency in real-world applications. (I'm working on a project with exactly this issue now...) I think that a balanced, informed view should be taken of strengths and weaknesses when considering any products. Let's not get too caught up in the FUD thing. FUD stands for Fear, Uncertainty and Doubt...and thats all it is. I note for example, that MySQL still have a benchmark page up that says something like "but we couldn't run PostgreSQL because VACUUM had a bug". Those things may be true, maybe not, but they are clearly both on significantly older releases and so both can and should be ignored. They can't be unsaid and arguing about it just makes you dance to their tune. Most importantly, PostgreSQL users should be confident that if IBM is saying bad things about PostgreSQL, its clearly on their radar - always the best compliment. That means we're not far off having some IBM staffers contributing regularly to the project... The new release will clear away any of those earlier comments. Best regards, Simon Riggs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On Mon, 12 Jul 2004, Joshua Kramer wrote:
>
> Last week, I got some DB2 literature from IBM. (I didn't ask for it, all
> I wanted was a CD with the software, but I guess they saw fit to send me
> the whole thing.) In this literature was a guide titled, "Why DB2 vs.
> Open Source Databases Sales Guide".
>
> The guide mostly concentrated on MySQL, but they did have one paragraph
> about PostgreSQL.
<snip>
This is called "marketing".
This year, someone asked me "Hwo do you compare PostgreSQL with MySQL?"
My answer was simple: "Oh, what's MySQL?"
He was surprised, and asked the same question about DB2. I replied: "I've
heard of it several years ago. Does IBM still support that product?"
Then I had a chance to tell that guy about the power of PostgreSQL. If I
compared PostgreSQL with MySQL or if I said "some" things abot DB2, then
he would think that I care for those databases...
...but I don't. We have PostgreSQL. World's most advanced Open Source
Database.
IBM concentrates their customers to MySQL since they know that MySQL is
not enough for any enterprise solutions. They say "Here is an Open Source
database. You saw that open source databases has no enterprise features.
So come back to DB2" and sell their customers lots of DB2 licences. If
they offered PostgreSQL, who would return to DB2?
Noone :)
Regards,
--
Devrim GUNDUZ
devrim~gunduz.org devrim.gunduz~linux.org.tr
http://www.tdmsoft.com
http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQFA87Pvtl86P3SPfQ4RAk3dAJ4vyjc1Dd9LR8lTj18HjnywXl2FGwCfb3qU
TdYZzDSYDuKb8ZogA8kCiIQ=
=NDfg
-----END PGP SIGNATURE-----
On Tue, 2004-07-13 at 03:47, Simon Riggs wrote: > I note for example, that MySQL still have a benchmark page up that says > something like "but we couldn't run PostgreSQL because VACUUM had a > bug". Those things may be true, maybe not, but they are clearly both on > significantly older releases and so both can and should be ignored. They > can't be unsaid and arguing about it just makes you dance to their tune. FYI, I think they dropped this page a while back (I can't find it in their docs online). But, they still list our maximum query size as 16 Megs, as that's the size of the buffer they declare to test with, and when it errors out at 16 Meg, they say that's our query limit. Of course, for quite some time now PostgreSQL has had no query size limit, only the one imposed by the hardware you're able to buy or with an unlimited budget, the largest machine made. They've been informed of this error, by me, on at least one occasion. They have not changed it. [1] > Most importantly, PostgreSQL users should be confident that if IBM is > saying bad things about PostgreSQL, its clearly on their radar - always > the best compliment. That means we're not far off having some IBM > staffers contributing regularly to the project... Good point. [1] More things they get wrong, that I've told them about in the past, that they haven't changed: The max buffer of 16 Meg affects a few other fields that they test (constant string size in SELECT and constant string size in where) which again has a limit of probably 1 gig right now.) Max table row length: 103279 (Actually 2 gig per field, several hundred fields at least, but they use the max length of char() for this? Not text? And only one field to test it?) It lists updates as non-atomic, although with select for update, PostgreSQL updates are fully atomic. It lists type for row id as oid, when serial would be more correct. They test for max and or with this query: select a from crash_me where a=1 and b='a' or a=0 and b='0' or a=1 and b='1' or a=2 and b='2' or a=3 and b='3' or a=4 and b='4' Notice any problem with the uselessness of the logic, at least test with something useful. They list the maximum number of arguments at 9999 with no footnote that this value is user settable via expression depth, the HINT tells you so. Maximum text listed as >8 meg, when in fact it's 128k times 8 meg as the max, typically (i.e. 1 gig) Of course most of this isn't malice, it's just not being familiar enough with PostgreSQL to know these things. I've pointed out these errors in the past, and gotten nary a peep for a response. Maybe I should try again.
> I'm also pretty sure that they laid off their PostgreSQL support staff > *before* the switchover to DB2; as you can imagine, they ran into some > problems in the interval. > > Merlin, if you can actually provide a link, I'm sure that Tim P. would be > happy to give us a statement refuting IBM's interpretation. My memory failed me. Here is the page I was thinking about (from his famous 2 part article comparing mysql and pg): http://www.phpbuilder.com/columns/tim20000705.php3?page=4 He never claimed that postgres was unstable, only that recovery was nasty when it did go down (which was true in the 6.5 - 7.0 days). In fact, he goes on to say that postgres was quite reliable. It could be extracted from his writings that there were crashes, however. This could be exploited in the usual nasty FUD way. It would be nice to see some uptime statistics from him IMO. Not really useful in a modern sense because it predates WAL, but it least to contrast what IBM is talking about... Merlin
On Tue, 2004-07-13 at 08:36, Merlin Moncure wrote: > It would be nice to see some uptime statistics from him IMO. Not really > useful in a modern sense because it predates WAL, but it least to > contrast what IBM is talking about... Since Tim went on to build GForge on top of PostgreSQL, I daresay he's a big fan. PostgreSQL is now powering all these sites: http://gforge.org/docman/view.php/1/52/gforge-sites.html Good times! Tom Copeland tom@infoether.com
On Tue, 2004-07-13 at 06:36, Merlin Moncure wrote: > > I'm also pretty sure that they laid off their PostgreSQL support staff > > *before* the switchover to DB2; as you can imagine, they ran into some > > problems in the interval. > > > > Merlin, if you can actually provide a link, I'm sure that Tim P. would > be > > happy to give us a statement refuting IBM's interpretation. > > My memory failed me. Here is the page I was thinking about (from his > famous 2 part article comparing mysql and pg): > http://www.phpbuilder.com/columns/tim20000705.php3?page=4 > > He never claimed that postgres was unstable, only that recovery was > nasty when it did go down (which was true in the 6.5 - 7.0 days). In > fact, he goes on to say that postgres was quite reliable. It could be > extracted from his writings that there were crashes, however. This > could be exploited in the usual nasty FUD way. > > It would be nice to see some uptime statistics from him IMO. Not really > useful in a modern sense because it predates WAL, but it least to > contrast what IBM is talking about... Tim wrote a followup article to that one, where he was testing the 7.1 series, it is interesting to see how much improvement he got from upgrading: http://www.phpbuilder.com/columns/tim20001112.php3?aid=151