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: