Обсуждение: DBMS Engines and Performance
I received a response from the development coordinator of an OSS business application I'd really like to use, but it works only with MySQL. The two reasons the one interested developer isn't devoting more time to the port are a lack of priority and paying sponsor. However, what puzzles me is this statement: "PostgreSQL has continued to fall behind other database engines in both performance and features, so I don't see compelling reason to work on it in my very limited free time." While I'm far from being totally in tune with the dbms universe, this doesn't look accurate to me. I recall from years ago that MySQL was tuned for speedy reads so that's why it was adopted for so many Web sites. But, hasn't it been only recently that its features and performance have caught up with Postgres? I don't intend to start a major thread as these issues have come up over time on this list. But, I would like some response from more knowledgeable folks on the quoted statement above, just for my own edification. Thanks, Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
In response to Rich Shepard <rshepard@appl-ecosys.com>: > I received a response from the development coordinator of an OSS business > application I'd really like to use, but it works only with MySQL. The > two reasons the one interested developer isn't devoting more time to the > port are a lack of priority and paying sponsor. > > However, what puzzles me is this statement: "PostgreSQL has continued to > fall behind other database engines in both performance and features, so I > don't see compelling reason to work on it in my very limited free time." Consider the source. If he chose to write for MySQL instead of PostgreSQL, he probably isn't up to speed on what's going on with PostgreSQL. PostgreSQL is anything but behind on both performance and features. > While I'm far from being totally in tune with the dbms universe, this > doesn't look accurate to me. I recall from years ago that MySQL was tuned > for speedy reads so that's why it was adopted for so many Web sites. But, > hasn't it been only recently that its features and performance have caught > up with Postgres? MySQL's features and performance have still not caught up with PostgreSQL. MySQL's ability to run benchmarks really fast has exceeded most other databases. Have a gander at the following link (for example): http://blog.page2rss.com/2007/01/postgresql-vs-mysql-performance.html > I don't intend to start a major thread as these issues have come up over > time on this list. But, I would like some response from more knowledgeable > folks on the quoted statement above, just for my own edification. I could be wrong, but I expect that a long thread is inevitable. -- Bill Moran Collaborative Fusion Inc.
Does the developer offer any hard evidence for his statement? I mean like benchmark tests and a side by side list of features? My impression is that Mysql is set up very narrowly for a typical ISP offering LAMP and not much else. Once you start going into corporate installations on private servers, you run into problems with Mysql. Some of the problems I've have personally are lack of anything that comes close to pgadmin and really arcane setup/maintenance. Rich Shepard wrote: > I received a response from the development coordinator of an OSS > business > application I'd really like to use, but it works only with MySQL. The > two reasons the one interested developer isn't devoting more time to the > port are a lack of priority and paying sponsor. > > However, what puzzles me is this statement: "PostgreSQL has > continued to > fall behind other database engines in both performance and features, so I > don't see compelling reason to work on it in my very limited free time." > > While I'm far from being totally in tune with the dbms universe, this > doesn't look accurate to me. I recall from years ago that MySQL was tuned > for speedy reads so that's why it was adopted for so many Web sites. But, > hasn't it been only recently that its features and performance have > caught > up with Postgres? > > I don't intend to start a major thread as these issues have come up > over > time on this list. But, I would like some response from more > knowledgeable > folks on the quoted statement above, just for my own edification. > > Thanks, > > Rich >
On Tue, 30 Jan 2007, Bill Moran wrote: > Consider the source. If he chose to write for MySQL instead of PostgreSQL, > he probably isn't up to speed on what's going on with PostgreSQL. Bill, It's 'they' rather than 'he,' but your point is still valid. > PostgreSQL is anything but behind on both performance and features. This is what I thought. Thank you for confirming. > MySQL's features and performance have still not caught up with PostgreSQL. > MySQL's ability to run benchmarks really fast has exceeded most other > databases. Have a gander at the following link (for example): > http://blog.page2rss.com/2007/01/postgresql-vs-mysql-performance.html I read this a few weeks ago when someone posted the URL to the list. Every installation and use is different enough from all the others to make generalizations inappropriate. Regardless, when anyone designs what is intended to be a broadly used business application _I_ belive that it should be designed from the very beginning to use any -- or most -- readily available database engines, if such is needed in the application. Why cut yourself off from a large segment of the market, even if the application is F/OSS? That just does not make business sense. However, this seems to be what every CRM/SFA[1] vendor/project team but one has choosen to do. The one exception uses postgres, but they bundle their application with 8.0.something, and we'd have to use both an earlier and different installation from what we already have here. That doesn't make business sense, either. > I could be wrong, but I expect that a long thread is inevitable. I hope that you are wrong. Preaching to the choir here is not going to make any difference to the folks who write these other applcations. So, repeating all the 'mine's bigger than yours' arguments will not convince anyone differently. :-) Many thanks, Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
On Tue, 30 Jan 2007, Mark Walker wrote: > Does the developer offer any hard evidence for his statement? I mean like > benchmark tests and a side by side list of features? Mark, No. And I've read this excuse from them before when I asked about a port. The application is written in php and they use adobp (or something like that) which is supposed to be backend-agnostic, but apparently still favors MySQL over PostgreSQL. No one in that glue project seems interested in fixing what's not working, either. > My impression is that Mysql is set up very narrowly for a typical ISP > offering LAMP and not much else. Once you start going into corporate > installations on private servers, you run into problems with Mysql. Some > of the problems I've have personally are lack of anything that comes close > to pgadmin and really arcane setup/maintenance. I remember the days when LAMP stood for Linux, Apache, Middleware, and PostgreSQL. :-) It's been co-opted, I guess. At last year's at O'Reilly's OSCON here in Portland I had this discussion with the booth babes sales droids from Sugar-CRM. They said that they heard numerous requests for postgres support but the decision-makers in the company were not interested in accommodating that segment of the market. So this is not an isolated instance. At the risk of going off the topic (but I won't respond on the list to any such posts), this attitude does not surprise me. It continues to disappoint me, but I've seen too many poorly managed companies to be surprised any longer. Across many industries I wonder why some companies manage to have survived as long as they have. Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
On Tue, 30 Jan 2007, Rich Shepard wrote: > business sense. However, this seems to be what every CRM/SFA[1] Oops! [1] Customer Relations Management/Sales Force Automation. Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/30/07 14:50, Rich Shepard wrote: > On Tue, 30 Jan 2007, Mark Walker wrote: > [snip] > At last year's at O'Reilly's OSCON here in Portland I had this discussion > with the booth babes sales droids from Sugar-CRM. They said that they heard > numerous requests for postgres support but the decision-makers in the > company were not interested in accommodating that segment of the market. So > this is not an isolated instance. > > At the risk of going off the topic (but I won't respond on the list to > any > such posts), this attitude does not surprise me. It continues to disappoint > me, but I've seen too many poorly managed companies to be surprised any > longer. Across many industries I wonder why some companies manage to have > survived as long as they have. The company might not have the resources to maintain 2 backends, or modify the whole system so that it is backend neutral. Maybe they use lots of MySQL-specific features that would make re-engineering it an arduous/imposible/expensive task, and thus not feasible. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFv7KrS9HxQb37XmcRAkamAJ0Q+mJndlO0UMQ4KilwBtoN6c6CaACfXahj uSE+flB2ql4C0rba5qTGJCE= =+EAM -----END PGP SIGNATURE-----
In response to Ron Johnson <ron.l.johnson@cox.net>: > > On 01/30/07 14:50, Rich Shepard wrote: > > On Tue, 30 Jan 2007, Mark Walker wrote: > > > [snip] > > At last year's at O'Reilly's OSCON here in Portland I had this discussion > > with the booth babes sales droids from Sugar-CRM. They said that they heard > > numerous requests for postgres support but the decision-makers in the > > company were not interested in accommodating that segment of the market. So > > this is not an isolated instance. > > > > At the risk of going off the topic (but I won't respond on the list to > > any > > such posts), this attitude does not surprise me. It continues to disappoint > > me, but I've seen too many poorly managed companies to be surprised any > > longer. Across many industries I wonder why some companies manage to have > > survived as long as they have. > > The company might not have the resources to maintain 2 backends, or > modify the whole system so that it is backend neutral. Maybe they > use lots of MySQL-specific features that would make re-engineering > it an arduous/imposible/expensive task, and thus not feasible. An interesting twist to this is that if you write your system to use PostgreSQL as the backend, you quickly start taking advantage of all the cool features that PostgreSQL has. This makes your coding easier, and your life easier, but badly breaks any compatibility with any other database. In my experience, it's easy to convert MySQL apps to run under Postgres -- it's very difficult to convert Postgres apps to MySQL, because MySQL just doesn't have the required features. -- Bill Moran Collaborative Fusion Inc.
On Tue, 30 Jan 2007, Ron Johnson wrote: > The company might not have the resources to maintain 2 backends, or modify > the whole system so that it is backend neutral. Maybe they use lots of > MySQL-specific features that would make re-engineering it an > arduous/imposible/expensive task, and thus not feasible. Ron, In the case of the system I'd like to use, it's not a company but a group of talented coders. And, they do use a lot of MySQL-specific features. If I had the money I'd sponsor the port, but I don't. I also don't have the time or expertise to underake it myself. Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
> However, what puzzles me is this statement: "PostgreSQL has continued > to > fall behind other database engines in both performance and features, so I > don't see compelling reason to work on it in my very limited free time." http://pda.tweakers.net/?reviews/649 http://pda.tweakers.net/?reviews/661 http://forums.mysql.com/read.php?25,93181,93181 http://london.pm.org/pipermail/london.pm/Week-of-Mon-20051219/000637.htm l http://mailman.fastxs.net/pipermail/dbmail/2006-December/010754.html I'm tired of teenage 1337 skill0rz PHP hackers who go "whoaah, 0ms!" after running "select count(*) from forum_posts" in a single thread (the developer himself testing his app), and then claim "MySQL rocks! I tested the postgres 7.1 that came with <insert linux distro of choice here>, but it was twice as slow!!!! Postgres sucks!" Ask them what they know about concurrency: transaction isolation level, MVCC vs. locking, and how they do when they test OLTP performance in highly concurrent scenarios, and I'm sure you'll get a "huh?" as an answer. Kids... ____________________________________________ Mikael Carneholm Systems Engineer WirelessCar AB
On Wed, Jan 31, 2007 at 09:57:21AM +0100, Mikael Carneholm wrote: > I'm tired of teenage 1337 skill0rz PHP hackers who go "whoaah, 0ms!" > after running "select count(*) from forum_posts" in a single thread (the > developer himself testing his app), and then claim "MySQL rocks! I > tested the postgres 7.1 that came with <insert linux distro of choice > here>, but it was twice as slow!!!! Postgres sucks!" Well, tell you what, twice 0ms is 0ms as well, so I guess "Postgre" don't suck as bad !! ;-)) Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
On Wed, 31 Jan 2007, Mikael Carneholm wrote: > I'm tired of teenage 1337 skill0rz PHP hackers who go "whoaah, 0ms!" after > running "select count(*) from forum_posts" in a single thread (the > developer himself testing his app), and then claim "MySQL rocks! I tested > the postgres 7.1 that came with <insert linux distro of choice here>, but > it was twice as slow!!!! Postgres sucks!" Mikael, This crew of developers is not made up of kids. We don't know their criteria for comparison of the two systems nor their experiences with them. I suspect a lot of attitude comes from belief, not fact. > Ask them what they know about concurrency: transaction isolation level, > MVCC vs. locking, and how they do when they test OLTP performance in > highly concurrent scenarios, and I'm sure you'll get a "huh?" as an > answer. It may well be that the XRMS CRM/SFA application does not use any of these features so their implementation in postgres and not mysql matters not to them. The most effective response, IMO, is for a group of talented and interested postgres developers to download the code, look for the MySQL-specific parts, translate them to PostgreSQL-acceptable syntax, and release it as a fork of the original. For quite a few months I monitored the mail list and saw many requests for help with installation, use, and actions not working. There is a lot of room for improvement. There is also ZohoCRM, which _is_ postgres based, but comes with version 8.0.something and no ability to use what we already have installed. That's another poor development decision. Why would I -- or anyone else -- want to intstall a second, older version of the dbms on their system, just to run a single application. As the head of a very small consulting company, I could benefit greatly from one of these CRM tools to track our marketing/sales efforts. From all I've seen xrms has the feature set I like the best, but I'll take any that work. I don't have the time, financial resources, or postgres/php skills to make the conversion on my own. I'm confident that I would not be the only happy beneficiary of a postgres port. Rich -- Richard B. Shepard, Ph.D. | The Environmental Permitting Applied Ecosystem Services, Inc. | Accelerator(TM) <http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863
On Wed, Jan 31, 2007 at 06:19:33AM -0800, Rich Shepard wrote:
> There is also ZohoCRM, which _is_ postgres based, but comes with version
> 8.0.something and no ability to use what we already have installed. That's
> another poor development decision. Why would I -- or anyone else -- want to
> intstall a second, older version of the dbms on their system, just to run a
> single application.
This problem seems way easier to me to fix than the MySQL-to-Postgres
port challenge. Not that the latter is hard, but it's time
consuming, and you end up with (as I already mentioned) all sorts of
ugly hairs that relate to MySQL "features" that are really just there
to cover up missing pieces of implementation. (Or rather,
used-to-be-missing. MySQL has come a long way in the past couple
releases, no matter what anyone thinks of their marketing approach of
FUD FUD FUD.)
--
Andrew Sullivan | ajs@crankycanuck.ca
If they don't do anything, we don't need their acronym.
--Josh Hamilton, on the US FEMA
On Tue, Jan 30, 2007 at 11:36:52AM -0800, Rich Shepard wrote:
> However, what puzzles me is this statement: "PostgreSQL has continued to
> fall behind other database engines in both performance and features, so I
> don't see compelling reason to work on it in my very limited free time."
While the claim is utter bosh, what is probably true is that an
application that has been designed exclusively to work well with
MySQL will just not work very well with Postgres. That's my
experience, in any case.
Generally, when you get an application that was designed exclusively
to work with MySQL, they're using all the furry little bits in MySQL
that aren't really very SQL-like. Then, the port is commenced, and
the developers discover that many of the MySQL tricks aren't really
SQL at all, and that they have a bunch of new syntax to learn.
Instead of regarding this as a failing of MySQL to implement
consistently the standard SQL, such developers often regard their
discovery of proof that only MySQL is a good product, that everything
else is garbage, and that all those other systems should just be
ignored.
The alternative approach is that the developers try to come up with
Yet Another Abstraction Layer, so that they can leave the code in
their system that is there to deal with the huge numbers of
historically missing features in MySQL. Even as MySQL has added some
of those features, the application designers haven't caught up.
The above is not universally true, but I have seen or read such
sentiments often enough to realise that there are plenty of
application developers who don't know anything about their database
technology.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
"The year's penultimate month" is not in truth a good way of saying
November.
--H.W. Fowler
Andrew Sullivan wrote:
> On Wed, Jan 31, 2007 at 06:19:33AM -0800, Rich Shepard wrote:
>> There is also ZohoCRM, which _is_ postgres based, but comes with version
>> 8.0.something and no ability to use what we already have installed. That's
>> another poor development decision. Why would I -- or anyone else -- want to
>> intstall a second, older version of the dbms on their system, just to run a
>> single application.
>
> This problem seems way easier to me to fix than the MySQL-to-Postgres
> port challenge. Not that the latter is hard, but it's time
> consuming, and you end up with (as I already mentioned) all sorts of
> ugly hairs that relate to MySQL "features" that are really just there
> to cover up missing pieces of implementation. (Or rather,
> used-to-be-missing. MySQL has come a long way in the past couple
> releases, no matter what anyone thinks of their marketing approach of
> FUD FUD FUD.)
The problem isn't so much MySQL anymore. It is developers unwilling to
force people to use MySQL 5. Heck, Drupal still supports version 3.x.
They are for version 6, dropping support for version 3 but still will be
supporting version 4.
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/