On Dec 12, 2007 12:33 PM, Ivan Sergio Borgonovo <mail@xxxxxxxxxxxxxxx> wrote:
> On Wed, 12 Dec 2007 09:01:59 -0800
> "Joshua D. Drake" <jd@xxxxxxxxxxxxxxxxx> wrote:
>
> > Those are the two I know best. We have several extremely high
> > profile customers that use Drupal & PostgreSQL with great success.
>
> May I ask you why they choose Postgres inspite of MySQL?
The two most common reasons a company chooses postgresql over MySQL
for these kinds of things are:
They already have a real db server running pgsql in house. If you've
spent $25,000 on your data warehouse machine, and it can handle the
drupal, RT, Jira, hyperic, snort, jive, bacula, custom RoR app, etc...
databases in it's spare time, why not use it for this as well.
Building a new MySQL server for one application makes the incremental
cost much higher.
> Drupal core works *nearly* painlessly with postgres but contrib
> modules aren't too Postgres friendly. Mainly because the Drupal
> community (as many CMS communities) is mysql centric or standard
> ignorant.
Mostly they just aren't familiar with anything else. It's not like
they hate the standards, but MySQL tends to teach bad habits, and this
means that apps developed first for MySQL tend to suffer from lots of
MySQL'isms
> Whenever I can Drupal is running on Postgres, mainly because there
> are applications dealing with money inside Drupal and
> a mature transaction, data integrity engine helps.
s/helps/is a necessity/
> Mysql feature are starting to look comparable if you skip the gotchas
> in places they will really come as an unpleasant surprise once you
> get used to pg coherence.
But the problem is it just LOOKS like they're comparable. They're
not. Sub selects still do pretty much only nested loop joins (i.e.
they're slow for large sets) and the query planner is dumb as a brick.
All of the features they're adding now are fresh and new, and may or
may not work all that well. Those same features have as much as a
decade or more of polishing and tuning in PostgreSQL.
> The fact that mysql runs on multiple engine
> may be a pro on the *long* run.
Seems to me each engine is a collection of compromises, most of which
I don't want to make. It's like by breaking up their work power over
so many different engine products, no one engine gets enough attention
to be really outstanding. The closest thing to a tuned, mature engine
that can handle transactions is innodb, and Oracle bought that, so who
knows where they're headed. The falcon table handler won't be done
for at least another year or two (i.e. truly production ready).
> But still Postgres is a safe harbour
> and it will be for some time to come.
And it's not like it's just sitting still, waiting for MySQL to pass
it by. The improvements in the last three years have been amazing in
terms of performance and capability. and with 8.3 there are some
very interesting performance enhancements for the subset of loads that
fit in memory and have high update rates, something that mysql has
traditionally beaten pgsql at.
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
