Обсуждение: MediaWiki + PostgreSQL is not ready for production?
I found following comment for using PostgreSQL with MediaWiki: https://www.mediawiki.org/wiki/Compatibility#Database "Anything other than MySQL or MariaDB is not recommended for production use at this point." This is a sad and disappointed statement for us. Should we help MediaWiki community to enhance this? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
On 7/18/2016 9:14 PM, Tatsuo Ishii wrote: > I found following comment for using PostgreSQL with MediaWiki: > > https://www.mediawiki.org/wiki/Compatibility#Database > > "Anything other than MySQL or MariaDB is not recommended for > production use at this point." > > This is a sad and disappointed statement for us. Should we help > MediaWiki community to enhance this? the classic problem with any of these sorts of open source projects, while you can convert the core system to postgres, there's a huge community of contributed plugins, and many of these authors have zero interest in anything but their default database, mysql/mariadb. I ran into this with Drupal, Wordpress, a couple different forum projects. Drupal even tried to offer a database API so plugin developers wouldn't touch SQL directly, but too many ignored it. -- john r pierce, recycling bits in santa cruz
> On 7/18/2016 9:14 PM, Tatsuo Ishii wrote: >> I found following comment for using PostgreSQL with MediaWiki: >> >> https://www.mediawiki.org/wiki/Compatibility#Database >> >> "Anything other than MySQL or MariaDB is not recommended for >> production use at this point." >> >> This is a sad and disappointed statement for us. Should we help >> MediaWiki community to enhance this? > > the classic problem with any of these sorts of open source projects, > while you can convert the core system to postgres, there's a huge > community of contributed plugins, and many of these authors have zero > interest in anything but their default database, mysql/mariadb. I ran > into this with Drupal, Wordpress, a couple different forum projects. > Drupal even tried to offer a database API so plugin developers > wouldn't touch SQL directly, but too many ignored it. Yeah, that's a classic problem. The reason why I raise the particular problem was, I hoped situations were better with MediaWiki since it has been used for PostgreSQL official site. But the truth is even MediaWiki is not an exception. My colleague has been working on making the latest version of WordPress work with PostgreSQL (there used be a PostgreSQL plugin but it has not been maintained and does not work with the latest version of WordPress). I imagine there are someone who are attacking the classic problem and I wonder as PostgreSQL community, what we can do for this. This may not be the brightest idea but what about starting with creating wiki page listing such that works? This will help users who want to use PostgreSQL with WordPress, MediaWikim Drupal etc. (and many plugins). Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
On 19/07/2016 10:20, Tatsuo Ishii wrote: >> On 7/18/2016 9:14 PM, Tatsuo Ishii wrote: >>> I found following comment for using PostgreSQL with MediaWiki: >>> >>> https://www.mediawiki.org/wiki/Compatibility#Database >>> >>> "Anything other than MySQL or MariaDB is not recommended for >>> production use at this point." >>> >>> This is a sad and disappointed statement for us. Should we help >>> MediaWiki community to enhance this? >> the classic problem with any of these sorts of open source projects, >> while you can convert the core system to postgres, there's a huge >> community of contributed plugins, and many of these authors have zero >> interest in anything but their default database, mysql/mariadb. I ran >> into this with Drupal, Wordpress, a couple different forum projects. >> Drupal even tried to offer a database API so plugin developers >> wouldn't touch SQL directly, but too many ignored it. > Yeah, that's a classic problem. The reason why I raise the particular > problem was, I hoped situations were better with MediaWiki since it > has been used for PostgreSQL official site. But the truth is even > MediaWiki is not an exception. > > My colleague has been working on making the latest version of WordPress > work with PostgreSQL (there used be a PostgreSQL plugin but it has not > been maintained and does not work with the latest version of > WordPress). I imagine there are someone who are attacking the classic > problem and I wonder as PostgreSQL community, what we can do for this. IMHO the way to solve this is not running to catch up with the various projects using a *SIMPLE* SQL backened, but rathercreate a new postgresql project providing a mysql compatibility layer, something like a server side parser that would translate the mysql commands to real SQL (PostgreSQL) statements. Then only one (this) project should be maintained, with no work wasted in specific client software. So, PostgreSQL can continue to do what it knows to do best, with no worries of not being natively compatible with simplisticyet proprietary systems like mysql. > > This may not be the brightest idea but what about starting with > creating wiki page listing such that works? This will help users who > want to use PostgreSQL with WordPress, MediaWikim Drupal etc. (and > many plugins). > > Best regards, > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > English: http://www.sraoss.co.jp/index_en.php > Japanese:http://www.sraoss.co.jp > > -- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt
John R Pierce wrote: > On 7/18/2016 9:14 PM, Tatsuo Ishii wrote: >> I found following comment for using PostgreSQL with MediaWiki: >> >> https://www.mediawiki.org/wiki/Compatibility#Database >> >> "Anything other than MySQL or MariaDB is not recommended for >> production use at this point." >> >> This is a sad and disappointed statement for us. Should we help >> MediaWiki community to enhance this? > > the classic problem with any of these sorts of open source projects, while you can convert the core > system to postgres, there's a huge community of contributed plugins, and many of these authors have > zero interest in anything but their default database, mysql/mariadb. I ran into this with Drupal, > Wordpress, a couple different forum projects. Drupal even tried to offer a database API so plugin > developers wouldn't touch SQL directly, but too many ignored it. > > > The quoted sentence is really more a statement on the Mediawiki product, NOT of Postgresql. The preceding half of the sentence makes that clear: "Support for any other database software ranges from dubious to stable..." It is not saying Postgresql is not ready for production, but that Mediawiki is not ready for production on a Postgresql. It's a wiki page. Could you edit the page and make the second sentence in that paragraph more explicit about what, exactly, it is that is not ready for production? Clearly, there is plenty of evidence that Postgresql is way ready from production use. In fact, now that page is fixed: "Running MediaWiki on anything other than MySQL or MariaDB is not recommended for production use at this point."
>> My colleague has been working on making the latest version of >> WordPress >> work with PostgreSQL (there used be a PostgreSQL plugin but it has not >> been maintained and does not work with the latest version of >> WordPress). I imagine there are someone who are attacking the classic >> problem and I wonder as PostgreSQL community, what we can do for this. > > IMHO the way to solve this is not running to catch up with the various > projects using a *SIMPLE* SQL backened, but rather create a new > postgresql project providing a mysql compatibility layer, something > like a server side parser that would translate the mysql commands to > real SQL (PostgreSQL) statements. > Then only one (this) project should be maintained, with no work wasted > in specific client software. > So, PostgreSQL can continue to do what it knows to do best, with no > worries of not being natively compatible with simplistic yet > proprietary systems like mysql. I'm not sure that's the best way ever. Sometimes the approach results in lesser performance of PostgreSQL than MySQL because of the SQL is not optimized for PostgreSQL. For toy project, that's fine. But for serious project it might bring bad performance and users will be disappointed and speak like "PostgreSQL is slower than MySQL". I saw that with Zabbix, for example. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
On 19/07/2016 12:05, Tatsuo Ishii wrote: >>> My colleague has been working on making the latest version of >>> WordPress >>> work with PostgreSQL (there used be a PostgreSQL plugin but it has not >>> been maintained and does not work with the latest version of >>> WordPress). I imagine there are someone who are attacking the classic >>> problem and I wonder as PostgreSQL community, what we can do for this. >> IMHO the way to solve this is not running to catch up with the various >> projects using a *SIMPLE* SQL backened, but rather create a new >> postgresql project providing a mysql compatibility layer, something >> like a server side parser that would translate the mysql commands to >> real SQL (PostgreSQL) statements. >> Then only one (this) project should be maintained, with no work wasted >> in specific client software. >> So, PostgreSQL can continue to do what it knows to do best, with no >> worries of not being natively compatible with simplistic yet >> proprietary systems like mysql. > I'm not sure that's the best way ever. Sometimes the approach results > in lesser performance of PostgreSQL than MySQL because of the SQL is > not optimized for PostgreSQL. For toy project, that's fine. But for > serious project it might bring bad performance and users will be > disappointed and speak like "PostgreSQL is slower than MySQL". I saw > that with Zabbix, for example. Better to run, even slowly, than not run at all, or require special porting team for every mysql client out there. > > Best regards, > -- > Tatsuo Ishii > SRA OSS, Inc. Japan > English: http://www.sraoss.co.jp/index_en.php > Japanese:http://www.sraoss.co.jp > > -- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt
On Tue, Jul 19, 2016 at 12:37:10PM +0300, Achilleas Mantzios wrote: > > Better to run, even slowly, than not run at all, or require special porting team for every mysql client out there. > I'm not sure I agree. If you teach every naïve user that, when they compare Postgres to MySQL, MySQL always wins, what you teach them is "Postgres performance sucks." Best regards, A -- Andrew Sullivan ajs@crankycanuck.ca
On 19/07/2016 12:41, Andrew Sullivan wrote: > On Tue, Jul 19, 2016 at 12:37:10PM +0300, Achilleas Mantzios wrote: >> Better to run, even slowly, than not run at all, or require special porting team for every mysql client out there. >> > I'm not sure I agree. If you teach every naïve user that, when they > compare Postgres to MySQL, MySQL always wins, what you teach them is > "Postgres performance sucks." It seems we have made already a verdict about mysql's code migrated to PostgreSQL being slow, although far fetched assumptionin itself, even if we accept it, it is far more productive having one dedicated small project for this mysql2pgsql conversion rather than N dedicated small teams for every mysql client out there. > > Best regards, > > A > -- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt
On Tue, Jul 19, 2016 at 12:55:09PM +0300, Achilleas Mantzios wrote: > It seems we have made already a verdict about mysql's code migrated to > PostgreSQL being slow Experience with designed-for-MySQL code that is modified to go through a so-called abstraction layer suggests that it will be. There are severaal anti-patterns in database use and access that are ubiquitous under MySQL because of early limitations in MySQL. Those uses are often optimised away in MySQL. Nevertheless, > we accept it, it is far more productive having one dedicated small project > for this mysql2pgsql conversion rather than N dedicated small teams for > every mysql client out there. …I don't think anyone is telling you, "Don't build this." You should do what you like with your time :) A -- Andrew Sullivan ajs@crankycanuck.ca
On 07/19/2016 12:20 AM, Tatsuo Ishii wrote: >> On 7/18/2016 9:14 PM, Tatsuo Ishii wrote: > My colleague has been working on making the latest version of WordPress > work with PostgreSQL (there used be a PostgreSQL plugin but it has not > been maintained and does not work with the latest version of > WordPress). I imagine there are someone who are attacking the classic > problem and I wonder as PostgreSQL community, what we can do for this. As I recall, WordPress has always maintained that it is a MySQL based engine and that any other database is non-supported. > > This may not be the brightest idea but what about starting with > creating wiki page listing such that works? This will help users who > want to use PostgreSQL with WordPress, MediaWikim Drupal etc. (and > many plugins). > It seems to me, the way to make this work is to have our members contribute to those projects to insure proper PostgreSQL support. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Tatsuo Ishii wrote: > "Anything other than MySQL or MariaDB is not recommended for > production use at this point." > > This is a sad and disappointed statement for us. It's more of a labelling problem than anything else at this point. Postgres support in MediaWiki may not be perfect, but it is really quite good at this point. There are plenty of places using Postgres and MediaWiki in production. MediaWiki has come a long way from its mysql-centric roots, and has a decent database abstraction layer. The wording used to be far worse, for the record. :) > Should we help. MediaWiki community to enhance this? Help is always welcome. If anyone wants some specific guidance or places to start, hit me up on IRC (freenode) on either #postgresql or #mediawiki, username G_SabinoMullane. The git/gerrit/phabricator process they use has a bit of a steep learning curve, but the code base is not too bad, considering it is written in PHP. Even if you can't code, there are lots of ways to help, from bug triage, to documentation writing, to simply test installing MediaWiki. See also: https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker https://phabricator.wikimedia.org/T2384 (Postgres support tracking) - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201607191015 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAleONnwACgkQvJuQZxSWSsgH+gCgr18yl6WJEvOB6cOePjq5TICG zWkAn1VEV7yCZHPo8SpzyDFUhBNEKRDc =5P2i -----END PGP SIGNATURE-----
> On Jul 18, 2016, at 11:47 PM, John R Pierce <pierce@hogranch.com> wrote: > > Drupal even tried to offer a database API so plugin developers wouldn't touch SQL directly, but too many ignored it. I have been using Drupal with PostgreSQL for more than 10 years without too many problems. Since version 7 all of Drupalcore works with PostgreSQL and I have encountered very few non-core modules that are MySQL specific. SQLite is alsoa core-supported database for Drupal. John DeSoi, Ph.D.
On 20/07/16 16:57, John DeSoi wrote: > >> On Jul 18, 2016, at 11:47 PM, John R Pierce <pierce@hogranch.com> >> wrote: >> >> Drupal even tried to offer a database API so plugin developers >> wouldn't touch SQL directly, but too many ignored it. > > I have been using Drupal with PostgreSQL for more than 10 years > without too many problems. Since version 7 all of Drupal core works > with PostgreSQL and I have encountered very few non-core modules that > are MySQL specific. SQLite is also a core-supported database for > Drupal. That's been my experience too. I remember some years ago a MySQL-ism in a query in the Nodequeue module was causing crashes on my Drupal/PostgreSQL installations; it was logged as a bug by the developers and fixed fairly quickly. Ray.
On 07/20/2016 08:57 AM, John DeSoi wrote: > >> On Jul 18, 2016, at 11:47 PM, John R Pierce <pierce@hogranch.com> wrote: >> >> Drupal even tried to offer a database API so plugin developers wouldn't touch SQL directly, but too many ignored it. > > I have been using Drupal with PostgreSQL for more than 10 years without too many problems. Since version 7 all of Drupalcore works with PostgreSQL and I have encountered very few non-core modules that are MySQL specific. SQLite is alsoa core-supported database for Drupal. Actually core has worked since 5. You are correct with 7, it is rare to find a popular external module that does not work with PostgreSQL. JD > > John DeSoi, Ph.D. > > > -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development. Everyone appreciates your honesty, until you are honest with them.
On Mon, Jul 18, 2016 at 10:14 PM, Tatsuo Ishii <ishii@postgresql.org> wrote: > I found following comment for using PostgreSQL with MediaWiki: > > https://www.mediawiki.org/wiki/Compatibility#Database > > "Anything other than MySQL or MariaDB is not recommended for > production use at this point." > > This is a sad and disappointed statement for us. Should we help > MediaWiki community to enhance this? A few years back I worked at a company that put mediawiki into our school content management system with postgresql. We had zero issues with postgresql support, it mostly just worked. Took us about 4 weeks to get it working and tested and deployed. The cool bit was that by creating a few triggers and views, we made mediawiki think it was just sitting on top of the default database when it fact it was sitting on top of our custom db. Each teacher / classroom had its own wiki, and we had literally 10s of thousands of independent wikis running, and they were plenty fast. -- To understand recursion, one must first understand recursion.