more anti-postgresql FUD
http://www.zabbix.com/manual/v1.1/install.php
in section PostgreSQL vs MySQL :
[quoting]
Regarding the choice between PostgreSQL and MySQL, MySQL is
recommended for several reasons:
* MySQL is faster
recent benchmarks using ZABBIX clearly show that PostgreSQL
(7.1.x) is at least 10 times slower than MySQL (3.23.29)
Note: These results are predictable. ZABBIX server processes use
simple SQL statements like single row INSERT, UPDATE and simple SELECT
operators. In such environment, use of advanced SQL engine (like
PostgreSQL) is overkill.
* no need to constantly run resource-hungry command "vacuum" for MySQL
* MySQL is used as a primary development platform.
If you do use PostgreSQL, zabbix_server will periodically (defined in
HousekeepingFrequency) execute command vacuum analyze.
[done]
anybody know these guys? this is right off the mysql anti-postgresql
advocacy page.
merlin
Merlin Moncure wrote:
http://www.zabbix.com/manual/v1.1/install.php
in section PostgreSQL vs MySQL :
[quoting]
Regarding the choice between PostgreSQL and MySQL, MySQL is
recommended for several reasons:* MySQL is faster
recent benchmarks using ZABBIX clearly show that PostgreSQL
(7.1.x) is at least 10 times slower than MySQL (3.23.29)Note: These results are predictable. ZABBIX server processes use
simple SQL statements like single row INSERT, UPDATE and simple SELECT
operators. In such environment, use of advanced SQL engine (like
PostgreSQL) is overkill.
* no need to constantly run resource-hungry command "vacuum" for MySQL
* MySQL is used as a primary development platform.If you do use PostgreSQL, zabbix_server will periodically (defined in
HousekeepingFrequency) execute command vacuum analyze.
[done]anybody know these guys? this is right off the mysql anti-postgresql
advocacy page.
Well they may be right that far back. But 7.1 is years and years old.
Joshua D. Drake
merlin
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
On 10/10/06, Joshua D. Drake <jd@commandprompt.com> wrote:
Merlin Moncure wrote:
http://www.zabbix.com/manual/v1.1/install.php
in section PostgreSQL vs MySQL :
Well they may be right that far back. But 7.1 is years and years old.
Joshua D. Drake
no excuse. that would be like postgresql having a documentation
chapter comparing nagios and zabbix for recommended network monitoring
tool and favoring nagios with advocacy information lifted from a
nagios developer's blog. while this is shady in and of itself, it
carries a burden of keeping the information up to date. if that was
in wikipedia i would be hitting the delete button.
FUD from another open source project is really poor form, particulary
when not in competing segements where a little bit of competitive
rivalry is expected.
merlin
Merlin Moncure wrote:
http://www.zabbix.com/manual/v1.1/install.php
in section PostgreSQL vs MySQL :
[quoting]
Regarding the choice between PostgreSQL and MySQL, MySQL is
recommended for several reasons:
I don't see any fear, uncertainty, or doubt there.
* MySQL is faster
It probably is for that application. Of course their references
benchmark is outdated, but that does not make it FUD.
* no need to constantly run resource-hungry command "vacuum" for
MySQL
Also a good, albeit outdated, reason.
* MySQL is used as a primary development platform.
Another good reason.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Peter Eisentraut <peter_e@gmx.net> writes:
* MySQL is used as a primary development platform.
Another good reason.
Actually that's *the* reason --- it's always going to be hard for
Postgres to look good for an application that's been designed/optimized
for MySQL. The application has already made whatever compromises it
had to for that platform, and dropping it onto a different DB won't
magically undo them.
Some days I think database independence is a myth.
regards, tom lane
mmoncure@gmail.com ("Merlin Moncure") writes:
http://www.zabbix.com/manual/v1.1/install.php
anybody know these guys? this is right off the mysql anti-postgresql
advocacy page.
On the upside, they actually indicated what versions they were working
with.
If they're so out of date that their documentation indicates they're
still using MySQL 3.23, it must be a spectacularly out of date
project, and therefore of little interest.
--
output = reverse("ofni.secnanifxunil" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/spiritual.html
A computer scientist is someone who, when told to "Go to Hell," sees
the "go to," rather than the destination, as harmful.
-- Dr. Roger M. Firestone, rfire@cais.cais.com
On 10/10/06, Peter Eisentraut <peter_e@gmx.net> wrote:
Merlin Moncure wrote:
http://www.zabbix.com/manual/v1.1/install.php
in section PostgreSQL vs MySQL :
[quoting]
Regarding the choice between PostgreSQL and MySQL, MySQL is
recommended for several reasons:I don't see any fear, uncertainty, or doubt there.
* MySQL is faster
It probably is for that application. Of course their references
benchmark is outdated, but that does not make it FUD.
ok, i'll grant that you are tecnically correct (not exactly FUD).
there seems to be no issue of intent here. however, if you are going
to compare two databases on a core feature such as performance, it's
important to keep your information up to date and factual. regardless
of the specifics in the document, it's important to consider the
perception of an uninformed person will come away with. this should
alse be considered in light of relatively public controversy (ableit
in narrow circles) surrounding some of the comments in the mysql
documentation in 2001.
merlin
MySQL 3.23.29 is pre-InnoDB
(http://dev.mysql.com/doc/refman/4.1/en/innodb-in-mysql-3-23.html), so
this database is not transactional, not ACIDic, and does not support
row-level locking or foreign key referential integrity. At this point,
MySQL lacked support for subqueries, UNIONs, VIEWs, and nearly
everything else beyond basic CRUD.
I bet I can design a program that interfaces flat data files so fast it
makes any RDBMS pale in comparison. SQLite does that, and it's ACID
compliant! Performance is not the only motivation for using an RDBMS.
Data integrity and relational modeling are also big considerations.
--
Brandon Aiken
CS/IT Systems Engineer
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Merlin Moncure
Sent: Tuesday, October 10, 2006 1:56 PM
To: PgSQL General
Subject: [GENERAL] more anti-postgresql FUD
http://www.zabbix.com/manual/v1.1/install.php
in section PostgreSQL vs MySQL :
[quoting]
Regarding the choice between PostgreSQL and MySQL, MySQL is
recommended for several reasons:
* MySQL is faster
recent benchmarks using ZABBIX clearly show that PostgreSQL
(7.1.x) is at least 10 times slower than MySQL (3.23.29)
Note: These results are predictable. ZABBIX server processes use
simple SQL statements like single row INSERT, UPDATE and simple SELECT
operators. In such environment, use of advanced SQL engine (like
PostgreSQL) is overkill.
* no need to constantly run resource-hungry command "vacuum" for
MySQL
* MySQL is used as a primary development platform.
If you do use PostgreSQL, zabbix_server will periodically (defined in
HousekeepingFrequency) execute command vacuum analyze.
[done]
anybody know these guys? this is right off the mysql anti-postgresql
advocacy page.
merlin
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
-----Original Message-----
Peter Eisentraut <peter_e@gmx.net> writes:* MySQL is used as a primary development platform.
Another good reason.
Actually that's *the* reason --- it's always going to be hard for
Postgres to look good for an application that's been
designed/optimized
for MySQL. The application has already made whatever compromises it
had to for that platform, and dropping it onto a different DB won't
magically undo them.Some days I think database independence is a myth.
We were looking to improve our session performance, so I did a basic
test of using mysql 4.0 innodb vs postgres 8.1. The test did a simple
retrieve, update, save; 1 time per page. mysql was stock, pg had a
shared_buffers and a couple of other standard tweaks done. ab was used
to provide the load. server was an old dell pe2450 with 640mb of ram.
tables were simple and a single primary key-foreign key relationship
between them.
pg was not only faster, it scaled to higher concurrency and had more
predictable response times. mysql nosed over at around 5 concurrent
connections. pg went to somewhere around 15.
the more I read, the more it seems that mysql speed is a myth. it may
be faster for simple flat-text sort of operations with one or two
concurrent users where the app maintains RI, validates all data, and
handles all of the complex joins. it just doesn't seem to scale up as
well as pg.
--
-Jacob
Import Notes
Resolved by subject fallback
Tom Lane <tgl@sss.pgh.pa.us> writes:
Some days I think database independence is a myth.
I believe it is as real as Santa Claus and the Easter Bunny. All of us know
that those three exist, right? :-)
--
Jorge Godoy <jgodoy@gmail.com>
"Jacob Coby" <jcoby@listingbook.com> writes:
We were looking to improve our session performance, so I did a basic
test of using mysql 4.0 innodb vs postgres 8.1. The test did a simple
retrieve, update, save; 1 time per page. mysql was stock, pg had a
shared_buffers and a couple of other standard tweaks done. ab was used
to provide the load. server was an old dell pe2450 with 640mb of ram.
tables were simple and a single primary key-foreign key relationship
between them.pg was not only faster, it scaled to higher concurrency and had more
predictable response times. mysql nosed over at around 5 concurrent
connections. pg went to somewhere around 15.the more I read, the more it seems that mysql speed is a myth. it may
be faster for simple flat-text sort of operations with one or two
concurrent users where the app maintains RI, validates all data, and
handles all of the complex joins. it just doesn't seem to scale up as
well as pg.
I'm sorry but you tuned PG and not MySQL. This by itself makes that claim a
problem. If you used PG stock versys MySQL stock, then it would be more
valid. When comparing two things you have to give them the most fair
condition that is possible (i.e., either put two experts to tune both or use
both as shipped by their suppliers).
Perharps if PG was shipped with more aggressive defaults then we'd have a
different set of results (I doubt that a developer who optimizes his code for
MySQL and says that on his website will have read about optimizing PG and done
something like that).
Using PG's advanced features (specially triggers, functions and rules) will
make it MUCH better than having to deal with things at code level like a MySQL
optimized project will do...
--
Jorge Godoy <jgodoy@gmail.com>
On Tue, Oct 10, 2006 at 06:25:21PM -0300, Jorge Godoy wrote:
"Jacob Coby" <jcoby@listingbook.com> writes:
We were looking to improve our session performance, so I did a basic
test of using mysql 4.0 innodb vs postgres 8.1. The test did a simple
retrieve, update, save; 1 time per page. mysql was stock, pg had a
shared_buffers and a couple of other standard tweaks done. ab was used
to provide the load. server was an old dell pe2450 with 640mb of ram.
tables were simple and a single primary key-foreign key relationship
between them.pg was not only faster, it scaled to higher concurrency and had more
predictable response times. mysql nosed over at around 5 concurrent
connections. pg went to somewhere around 15.the more I read, the more it seems that mysql speed is a myth. it may
be faster for simple flat-text sort of operations with one or two
concurrent users where the app maintains RI, validates all data, and
handles all of the complex joins. it just doesn't seem to scale up as
well as pg.I'm sorry but you tuned PG and not MySQL. This by itself makes that claim a
problem. If you used PG stock versys MySQL stock, then it would be more
valid. When comparing two things you have to give them the most fair
condition that is possible (i.e., either put two experts to tune both or use
both as shipped by their suppliers).
Not necessarily. Last I heard, MySQL ships with multiple config files,
ie: small, medium and large. So by choosing one of those you're
effectively tuning MySQL as well.
If you want a real apples-apples out-of-the-box, run MySQL with a small
config and PostgreSQL stock.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On Tue, Oct 10, 2006 at 02:50:44PM -0400, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
* MySQL is used as a primary development platform.
Another good reason.
Actually that's *the* reason --- it's always going to be hard for
Postgres to look good for an application that's been
designed/optimized for MySQL. The application has already made
whatever compromises it had to for that platform, and dropping it
onto a different DB won't magically undo them.Some days I think database independence is a myth.
I do, too, but only on the weekdays ending in 'y' ;)
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
On Tue, 2006-10-10 at 14:50 -0400, Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
* MySQL is used as a primary development platform.
Another good reason.
Actually that's *the* reason --- it's always going to be hard for
Postgres to look good for an application that's been designed/optimized
for MySQL. The application has already made whatever compromises it
had to for that platform, and dropping it onto a different DB won't
magically undo them.Some days I think database independence is a myth.
If it's not even possible to get trustworthy, duplicate renderings of
XHTML/CSS on popular browsers without tweaks, we can truly never expect
something as utopian as that.
Sadly.
Andy
Hello,
I'm author and maintainer of ZABBIX and the manual. I would like to add
some comments to the thread.
First of all, ZABBIX supports three database engines: MySQL, Oracle and
PostgreSQL. It uses absolutely standard SQL, same for all three
database engines. We have absolutely no intention to push or recommend
one of those. I'm big fan of PostgreSQL and having a choice I would
choose PostgreSQL for anything except ZABBIX.
Unfortunately PostgreSQL performs much slower than MySQL doing large
number of updates for one single table. By its nature ZABBIX requires
to execute hundreds of updates per second for large installations.
PostgreSQL cannot handle this nicely.
Do a simple test to see my point:
1. create table test (id int4, aaa int4, primary key (id));
2. insert into test values (0,1);
3. Execute "update test set aaa=1 where id=0;" in an endless loop
I just did the test on PostgreSQL 7.4.12 and MySQL 5.0.22 (MyISAM,
sorry had no configured InnoDB). Ubuntu 6.0.6, AMD64, 2GB, default
database settings.
MySQL performs very well, approximately 15000-20000 updates per second
with no degradation of performance.
PostgreSQL does approximately 1600 records per second for the first
10000, then 200rps for the first 100k records, and then slower and
slower downgrading to 10-20 rps(!!!) when reaching 300k.
The manual states that PostgreSQL works ten times slower for ZABBIX, in
reality it is much worser.
Yes, I'm aware of autovacuuming, etc. But it eats resources and I
cannot handle to run it periodically because I want steady performance
from my application. I do not want to see ZABBIX performing slower just
because of database housekeeper.
Several years ago I contacted PostgreSQL developers but unfortunately
the only answer was "Run vacuum. We won't change PostgreSQL to reuse
unused tuples for updates".
Perhaps something has changed in recent releases of PostgreSQL, I don't
think so. Please correct me if I'm wrong.
Kind regards,
Alexei
On Tue, Oct 10, 2006 at 02:50:44PM -0400, Tom Lane wrote:
Some days I think database independence is a myth.
On the day when you don't, please tell me what application you found
where it isn't. I want to buy the developers a drink. Or maybe a
bar.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
When my information changes, I alter my conclusions. What do you do sir?
--attr. John Maynard Keynes
Andrew Sullivan wrote:
On Tue, Oct 10, 2006 at 02:50:44PM -0400, Tom Lane wrote:
Some days I think database independence is a myth.
On the day when you don't, please tell me what application you found
where it isn't. I want to buy the developers a drink. Or maybe a
bar.
The Mantis bug tracking software http://www.mantisbt.org/ now works with
PostgreSQL (was developed with MySQL.) It works equally well with both,
including automated installation.
--
Guy Rouillier
Andrew Sullivan wrote:
On Tue, Oct 10, 2006 at 02:50:44PM -0400, Tom Lane wrote:
Some days I think database independence is a myth.
On the day when you don't, please tell me what application you found
where it isn't. I want to buy the developers a drink. Or maybe a
bar.
Command Prompt will help sponsor that community event ;)
Joshua D. Drake
A
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Guy Rouillier wrote:
Andrew Sullivan wrote:
On Tue, Oct 10, 2006 at 02:50:44PM -0400, Tom Lane wrote:
Some days I think database independence is a myth.
On the day when you don't, please tell me what application you found
where it isn't. I want to buy the developers a drink. Or maybe a
bar.The Mantis bug tracking software http://www.mantisbt.org/ now works with
PostgreSQL (was developed with MySQL.) It works equally well with both,
including automated installation.
I find that "database independence" == "lowest common denominator". I
may have missed something, but a quick scan of the Mantis code didn't
reveal any use of triggers, rules, foreign-keys, user-defined types, etc.
Whenever I see that a project has been "ported" to PostgreSQL I can
usually be sure that it is not a project that was designed to take
advantage of the features and capabilities that PG offers.
But I suspect that porting something that uses all the features of mySql
to PostgreSQL will be far easier than porting something that uses all
the features of PostgreSQL over to mySql (if it is possible at all).
Cheers,
Steve
ajs@crankycanuck.ca (Andrew Sullivan) writes:
On Tue, Oct 10, 2006 at 02:50:44PM -0400, Tom Lane wrote:
Some days I think database independence is a myth.
On the day when you don't, please tell me what application you found
where it isn't. I want to buy the developers a drink. Or maybe a
bar.
You're sitting across the street from the local headquarters of the
vendor of just such an application.
Of course, they don't use foreign keys, triggers, dates are
represented as char(10), and validity checking is expected to be coded
into either (traditionally) transaction screens or (new technologies)
BAPIs (Business APIs). Really, the application was designed with IMS
<http://en.wikipedia.org/wiki/Information_Management_System> in mind.
And *they* can afford to pay for a whole bar, once you pay the annual
licensing fee :-(.
Oh, and a cluster of IBM p570s would probably be enough to run a 20
user system :-(. [Actually, that's probably not *entirely* fair; I
once administered an R/3 system supporting ~30 users on a uniprocessor
DEC Alpha with 256MB of RAM, which by modern standards is pretty
pedestrian...]
--
(format nil "~S@~S" "cbbrowne" "linuxdatabases.info")
http://www3.sympatico.ca/cbbrowne/sap.html
"Access to a COFF symbol table via ldtbread is even less abstract,
really sucks in general, and should be banned from earth."
-- SCSH 0.5.1 unix.c
