SEO

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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/pos...rformance.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.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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
>


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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/pos...rformance.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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org/

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

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

-----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+mJndlO0UMQ4KilwBt oN6c6CaACfXahj
uSE+flB2ql4C0rba5qTGJCE=
=+EAM
-----END PGP SIGNATURE-----

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

> 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/londo...219/000637.htm
l
http://mailman.fastxs.net/pipermail/...er/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


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend