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

From Jean-Michel Pouré
Subject Re: 8.5 release timetable, again
Date
Msg-id 1251299887.11115.22.camel@acer
Whole thread Raw
In response to Re: 8.5 release timetable, again  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: 8.5 release timetable, again
Re: 8.5 release timetable, again
Re: 8.5 release timetable, again
List pgsql-hackers
Le mercredi 26 août 2009 à 09:30 -0500, Kevin Grittner a écrit :
> It's not clear to me what you feel is needed.  That could mean many
> things....

Dear Kevin,

I rarely post on Hackers, so I will try to explain:
* I use PostgreSQL since 1998.
* I took part in the development of pgAdmin 1&2.
* I love PostgreSQL and I believe MySQL sucks. Recently I was forced to
use MySQL for Kdenlive.org project and the database sometimes stops
responding sending nothing or crap. I believe that if you use MySQL in
your company for a paid work, you can die of a heart attack.

But at the same time:
* I rewrote very long and tedious queries from PHPBB. Maybe 100 of them.
They are now part of PhpBB3. I drove all queries below 30 ms and this
enables PhpBB to scale easily. I consider this is my work.
* I think Drupal queries presently have performance problems. If I
wanted, I would be able to drive down Drupal web site, using a
collection of simple queries on projects, forum and comments. But I
don't of course.

This is why I wrote http://drupal.org/node/559302 and
http://drupal.org/node/555514

Everytime I try a new Drupal module under PostgreSQL, I run into tiny
SQL problems ranging from error to performance drop. The most
problematic problem is http://drupal.org/node/559986

To fix a problem, I need to open a thread on Drupal web site and wait
for the maintainer to discuss and commit.

To give an example, Drupal includes a query optimizer written in PHP,
which sometimes adds "DISTINCT" to queries. In the forum, some
incredible query fetches 22000 rows, copies the rows to an arrays and
then computes the array. This allows to display previous and next
message.

But we are not going to change the world of MySQL users, which believe
they know SQL programming and in reality are complete beginners, who
like to boast about farms and replication, just like Windows users like
to collect Adobe products on DVDs and discuss with friends about them.

IMHO for what I know from the porting work (I worked heavily on PHPBB3
and now Drupal), the first goal is to achieve compatibility with issues
mentioned there: http://drupal.org/node/555514 and add mysql compat
functions in PostgreSQL core without breaking existing code.

Then I can insure that 99% of MySQL compatibility problems will be
behind.

When this is achieve, we will be able to start education of developers.
And this will take another decade.

To win over MySQL, the best is to work on materialized views. There are
very good articles available from hackers. Why not port to C.
Materialized which which update when the data is needed would be
perfect.

Then we can convince Drupal hackers to add views in the schema. The
trick would be that MySQL would support normal views, whereas we would
also support materialized. We can do the same with nearly all available
frameworks: PhpBB, etc ...

Web apps are 95% of PostgreSQL possible users.

Kind regards,
Jean-Michel

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: We should Axe /contrib/start-scripts
Next
From: Andrew Dunstan
Date:
Subject: Re: 8.5 release timetable, again