Re: 8.5 release timetable, again - Mailing list pgsql-hackers

From Rick Gigger
Subject Re: 8.5 release timetable, again
Date
Msg-id 4E1B1701-67AE-4ED5-A8CA-AD1B0CFB77CC@alpinenetworking.com
Whole thread Raw
In response to Re: 8.5 release timetable, again  (Jean-Michel Pouré <jm@poure.com>)
List pgsql-hackers
On Aug 26, 2009, at 8:17 AM, Jean-Michel Pouré wrote:

> Le mercredi 26 août 2009 à 01:36 -0600, Rick Gigger a écrit :
>> One possible reason that replication is more critical now than it
>> was
>> a year ago is the rise in cloud computing.  The ability to fire up
>> instances on demand is much more useful when some of those boxes can
>> be database servers and those databases servers can replicate the
>> primary database and start doing something useful.  As far as I can
>> tell this one feature alone is the one thing that makes it hard to
>> convince people to migrate away from Mysql despite it's demonstrable
>> inferiority in many other areas.
>
> I think you should have a deep look at
> these two manuals that I wrote for Drupal:
>
> Guidelines for writing MySQL and PostgreSQL compliant SQL
> http://drupal.org/node/555514
>
> and
>
> Quidelines for writing SQL efficient code:
> http://drupal.org/node/559302
>
> I have been using PostgreSQL since 1998. I took part in the
> development
> of pgAdmin 1 and pgAdmin 2. I am very proud of the PostgreSQL
> community,
> but I think it should fix some important issues in the domain of SQL
> compliance and compatibility.
>
> When reading developers comments on Drupal web site, it seems that
> there
> is deep misunderstanding between developers and SQL databases. I would
> say that 1% of developers know database technology. For example, most
> Drupal developers think that an INNER JOIN is faster than a LEFT JOIN.
>
> The reality of facts is that developers will not even test PostgreSQL
> and stop using it after the first SQL warning or error.
>
> So I would recommend focussing on usability.
>
> Then you can work on replication and materilized views. You probably
> know that a cloud requires several computers. With materialized
> view, a
> single computer can perform 100 times better. I see plenty of of
> possibilities to improve speed using materialized views.
>
> But first and firstly ... focus on usability. Then make a pre-
> release of
> a PostgreSQL 8.4.2 release or so ... We need to wipe out this MySQL
> issue once for all.
>
> If there is a compat MySQL mode or functions, then include it in core.
> This is too important for PostgreSQL success.
>
> Why MySQL usability is achieved add materialized views and MySQL is
> dead
> in the performance statistics, beaten 99% by PostgreSQL.

This may be your experience and maybe there are stats to back this
up.  I was simply saying, that in my experience I have consulted with
companies using cloud computing services (ie EC2) and mysql.  They are
performance conscious.  When they have to fire up more boxes, they pay
for it immediately.  When they ran into problems getting good
performance out of mysql it was very easy to show them how to get
better performance using postgres.  (Often this was just: do the same
thing in postgres, and look, it's faster!).  But they also rely on
replication to be able to scale.  And without it they just weren't
interested.

Porting any project has it's own set of issues, I was speaking to the
case where people are evaluating databases for a new project.  I was
not however trying to make any kind of statement as too how important
it is as compared to any other specific feature.

I was just trying to say that in my experience current trends indicate
that having easy to set up replication is getting more important over
time, not less, and not the same.  Other features may be more
important.  Getting it right is certainly more important that getting
it soon (for reasonable values of "soon" and "right" of course IMHO).
The experience of others my be totally different, but that is mine.

Just wanted to clarify what I was actually trying to say because this
response seems to indicate that I didn't make certain things clear.

- Rick





pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: We should Axe /contrib/start-scripts
Next
From: Andrew Dunstan
Date:
Subject: Re: pretty print viewdefs