Thread: Re: PostgreSQL vs MySQL

David,

Thanks for being considerate, thourough, and honest about your opinions.
Particulary that you didn't simple depart in a huff.

> 1) the MySQL docs are better (sorry - I found them easier to read, and
> more comprehensive; I had an easier time finding the answers I needed)

I can believe that.   MySQL AB has paid documentation writers; we don't.

> 2) there are more web pages devoted to MySQL (probably because it has a
> bit more market share)

Particularly among web developers.

> 3) there are more books on MySQL at the bookstore (I haven't had a
> chance to pick up Bruce's book yet; it might be all the book I'd ever
> need)

Bruce's book is out of date -- released in 1998.  I recommend Korry Douglas'
book instead, just because of its up-to-date nature (printed late 2002 or
early 2003).

> 4) we looked at MySQL first (we needed replication, and eRServer had not
> been open-sourced when we started looking)

I can't do anything about that, now can I?

> With regards to #1, I'd like to specifically mention tuning - the docs
> at http://www.postgresql.org/docs/7.3/static/runtime-config.html
> <http://www.postgresql.org/docs/7.3/static/runtime-config.html>  give a

Have you checked these pages?  They've been posted on this list numerous
times:
http://techdocs.postgresql.org
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html

Also, the runtime docs are being improved in 7.4:
http://developer.postgresql.org/docs/postgres/runtime-config.html
... and I'm still working on more general "how to" text.

> "I guess my point is simply this: instead of saying: "okay we use
> default settings that will run on _old_ hardware too" we should go for a
> little script that creates a "still save but much better" config file.
> There's just no point in setting SHARED_BUFFERS to something like 16
> (what's the current default?) if the PC has >= 1 GB of RAM. Setting it
> to 8192 would still be save, but 512 times better...  ;-) (IIRC 8192
> would take 64 MB of RAM, which should be save if you leave the default
> MAX_CONNECTIONS.)"

You'll be interested to know that SHARED_BUFFERS are actually addressed in the
initdb script in 7.4.  However, may OSes have low limits on per-process
memory that requires the admin to modify the sysconf before postgresql.conf
can be adjusted properly.  This makes writing a multi-platform tuning script
a significant effort, and to date nobody who is complaining about it the
loudest has volunteered to do the work.

To reiterate my point above, PostgreSQL is a 100% volunteer Open Source
project.  MySQL is a commercial company which distributes its products via
Open Source licensing.  That makes some things easier for them than for us
(and vice-versa, of course).

> I also have to admit a bit of irritation reading this thread; there is a
> fair number of incorrect statements on this thread that, while not
> wrong, definately aren't right:

We've been working on this on the advocacy list .... that is, giving an
accurate listing of PostgreSQL features not posessed by MySQL (same for
Oracle and DB2 as well, MySQL is just easier to start becuase we don't have
to worry about being sued).   I'd appreciate it if you'd take an interest in
that document and revise anything which is innaccurate or perjorative.

Also, keep in mind that many members of the PostgreSQL community have "an axe
to grind" about MySQL.  This is not only because of MySQL's eclipsing us in
the popular press as "THE open source database"; it is also because prominent
individuals at MySQL AB, particularly Monty and David Axmark, have in the
past signaled their intent to rub out all other OSS databases, starting with
PostgreSQL.   While this says little about the MySQL community, it does make
members of our communty very touchy when the "M" word comes up.

I quote the rest of your debunking for the benefit of the readers on the
Advocacy list, with a couple of comments:

> "Speed depends on the nature of use and the complexity of queries.  If
> you are doing updates of related tables, ACID is of vital importance and
> MySQL doesn't provide it."
> MySQL has ACID in InnoDB. I've found that MySQL is actually very fast on
> complex queries w/InnoDB (six tables, 1 million rows, two of the joins
> are outer-joins. In fact, I can get InnoDB to be almost as fast as
> MyISAM. Complex updates are also very very fast. We have not tried
> flooding either database with dozens of complex statements from multiple
> clients; that's coming soon, and from what I've read, MySQL won't do too
> well.
>
> "using InnoDB tables (the only way to have foreign keys, transactions,
> and row level locking for MySQL) makes MySQL slower and adds complexity
> to tuning the database"
> Adding this: "innodb_flush_method=O_DSYNC" to the my.cnf made InnoDB as
> fast as MyISAM in our tests. It doesn't turn off disk flushing; it's
> just a flush method that might work better with different kernels and
> drives; it's one of those "play with this and see if it helps"
> parameters; there are lots of those in Postgres, it seems. There are 10
> variables for tuning InnoDB (and you don't have to tune for MyISAM, so
> it's actually a six-of-one, half-dozen-of-the-other). Setup between the
> two seems to be about the same.
>
> "PostgreSQL supports constraints. MySQL doesn't; programmers need to
> take care of that from the client side"
> Again, InnoDB supports constraints.

Really?  This is news.   We did some tests on constraints on InnoDB, and found
that while they parsed, they were not actually enforced.    Was our test in
error?

> "Transactions: We've been here before. Suffice to say, MySQL+InnoDB is
> almost there. Plain ol' MySQL doesn't have it, which tells you something
> about their philosophy towards database design."
> InnoDB supports transactions very nicely, has the equivalent of WAL, and
> one thing I really like: a tablespace (comprised of data files that can
> be spread around multiple hard drives), and in a month or so, InnoDB
> will support multiple tablespaces.

We'll have multiple tablespaces soon as well.  They didn't quite make it for
7.4, but will be in 7.5.

> To be fair, here are a few MySQL "bad-things" that weren't mentioned:
>
> 1) InnoDB can't do a hot-backup with the basic backup tools. To
> hot-backup an InnoDB database, you need to pay $450 US per database per
> year ($1150 per database perpetual) for a proprietary hot-backup tool
> 2) InnoDB can't do full-text searching.
> 3) I see alot more corrupt-database bugs on the MySQL lists (most are
> MyISAM, but a few InnoDB bugs pop up from time to time) - way more than
> I see on the Postgres lists.

This is consistent with MySQL's emphasis on speed and ease-of-use over
reliability; we have the opposite emphasis (see below).

> 4) There are some really cranky people on the MySQL lists; the Postgres
> lists seem to be much more effective (esp. with people like Tom Lane).
> Maybe it's because they get alot of dumb questions, as people unfamiliar
> with databases turn to MySQL first?

Possibly.  Also I think it's because of the poor organization of their mailing
lists; ours are clearly divided into particular topics and experienced
members politiely encourage toplicality.   Further, the participation by
major contributors on our lists is, from what I've heard, higher; this means
that complaintants have faith that their complaints will reach the eyes of
those actually responsible for the code.

> Maybe the Postgres community needs an anti-FUD individual or two; people
> that know both databases, and can provide the proper information for
> answering questions like this. A section in the docs would help as well.
> Yes, I know many of the people advocating Postgres do not want to
> compare themselves to MySQL (but rather to Oracle, Sybase, DB2, etc) ,
> but the volume of responses on a thread like this indicates that the
> comparison is going to happen regardless. Better to nip it in the bud
> quickly than let it go on over 3-4 days.

Would you care to volunteer?   We'd be glad to have you.

> One last observation: someone looking at both databases, reading those
> posts, might get a bad impression of Postgres based on the inconsistency
> and incorrectness of some of the statements made about MySQL. If a
> salesperson provides misinformation about a competitors product and you
> find out about it, that salesperson has most likely lost a customer.

Maybe.  Not that I'm saying that inaccurate propaganda is a good thing, but
that it seems so pervasive in the industry that I think people expect it.  We
trash MySQL; MySQL publishes 6-year-old PG vs. MySQL benchmarks; Oracle puts
down all Open Source databases based on MySQL's limitations; and MS SQL
Server publishes benchmarks based on MSSQL on a cluster vs. other DBs on
workstations.

> Anyway, I hope I haven't offended anyone - I'm not trying to troll or
> flame, but rather just give some constructive criticism from someone
> outside both the MySQL and Postgres camps.

Hmmm .... also, come to think about it, MySQL has done us a favor in some ways
by making our project take advocacy and user-friendliness seriously,
something we didn't always do.

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Thu, 9 Oct 2003, David Griffiths wrote:

> 1) the MySQL docs are better (sorry - I found them easier to read, and
> more comprehensive; I had an easier time finding the answers I needed)

Huh. I had the opposite experience. Each to his own.
I think everybody agrees PG needs a better tuning doc (or pointers to it,
or something).

> "Speed depends on the nature of use and the complexity of queries.  If
> you are doing updates of related tables, ACID is of vital importance and
> MySQL doesn't provide it."

I don't know if you looked at my presentation. But in preparation for it I
checked out MySQL 4.0.x[most recent stable]. I found that I violates the C
in acid in some places. ie you can insert a date of 0000/00/00 and have it
sit there and be fine.  Perhaps this is the fault of mysql's timestamp
type.

> MyISAM. Complex updates are also very very fast. We have not tried
> flooding either database with dozens of complex statements from multiple
> clients;

You don't need complex statements to topple mysql over in high
concurrency. I was doing fairly simple queries with 20 load generators -
it didn't like it.  Not at all (mysql: 650 seconds pg: 220)

> 3) I see alot more corrupt-database bugs on the MySQL lists (most are
> MyISAM, but a few InnoDB bugs pop up from time to time) - way more than
> I see on the Postgres lists.

I saw this as well. I was seeing things in the changelog as late as
september (this year) about fixing bugs that cause horrific corruption.
That doesn't make me feel comfy.  Remember - in reality InnoDB is still
very new.  The PG stuff has been tinkered with for years.  I like
innovation and new things, but in some cases, I prefer the old code
that has been looked at for years.


--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/

> Have you checked these pages?  They've been posted on this list numerous
> times:
> http://techdocs.postgresql.org
> http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
> http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html
>

Josh- It would be great to have a link to those last two excellent resources
from the techdocs area- perhaps from the "optimizing" section in
http://techdocs.postgresql.org/oresources.php. Who should we suggest this
to? (I submitted these using the form in that area, but you may have better
connections.)

-Nick

Nick,

> Josh- It would be great to have a link to those last two excellent resources
> from the techdocs area- perhaps from the "optimizing" section in
> http://techdocs.postgresql.org/oresources.php. Who should we suggest this
> to? (I submitted these using the form in that area, but you may have better
> connections.)

This is my  responsibility;  I'll add it to the list.

--
-Josh Berkus
 Aglio Database Solutions
 San Francisco

On Thu, 9 Oct 2003, Josh Berkus wrote:

> David Griffiths wrote:
> > With regards to #1, I'd like to specifically mention tuning - the docs
> > at http://www.postgresql.org/docs/7.3/static/runtime-config.html
> > <http://www.postgresql.org/docs/7.3/static/runtime-config.html>  give a
>
> Have you checked these pages?  They've been posted on this list numerous
> times:
> http://techdocs.postgresql.org
> http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
> http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html
>
> Also, the runtime docs are being improved in 7.4:
> http://developer.postgresql.org/docs/postgres/runtime-config.html
> ... and I'm still working on more general "how to" text.

any chance of getting the perf.html file from varlena folded into the main
documentation tree somewhere?  it's a great document, and it would
definitely help if the tuning section of the main docs said "For a more
thorough examination of postgresql tuning see this:" and pointed to it.

On Thu, 9 Oct 2003, Jeff wrote:

> On Thu, 9 Oct 2003, David Griffiths wrote:
>
> > 1) the MySQL docs are better (sorry - I found them easier to read, and
> > more comprehensive; I had an easier time finding the answers I needed)
>
> Huh. I had the opposite experience. Each to his own.
> I think everybody agrees PG needs a better tuning doc (or pointers to it,
> or something).

I think the issue is that Postgresql documentation is oriented towards DBA
types, who already understand databases in general, so they can find what
they want, while MySQL docs are oriented towards dbms newbies, who don't
know much, if anything, about databases.

I concur 100%. PostgreSQL was big and scary and MySQL seemed cute and
cuddly, warm and fuzzy. Then I took my undergrad CS RDBMS course (a course
that focused on designing the backend software), and only then was I ready
to appreciate and wield the battle axe that is PostgreSQL.

He also let me use PostgreSQL for my final project (the standard was
Oracle). I got an A. :)

I do have to admit that I prefer OSS (and docs) better than proprietary. I
had some Informix work and that was not fun at all. So even though the MySQL
is pink fuzzy bunnies, PostgreSQL is at least a brown fuzzy bunny [to me
anyway].

> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org]On Behalf Of
> scott.marlowe
> Sent: Thursday, October 09, 2003 3:26 PM
> To: Jeff
> Cc: David Griffiths; pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] PostgreSQL vs MySQL
>
>
> On Thu, 9 Oct 2003, Jeff wrote:
>
> > On Thu, 9 Oct 2003, David Griffiths wrote:
> >
> > > 1) the MySQL docs are better (sorry - I found them easier to read, and
> > > more comprehensive; I had an easier time finding the answers I needed)
> >
> > Huh. I had the opposite experience. Each to his own.
> > I think everybody agrees PG needs a better tuning doc (or
> pointers to it,
> > or something).
>
> I think the issue is that Postgresql documentation is oriented
> towards DBA
> types, who already understand databases in general, so they can find what
> they want, while MySQL docs are oriented towards dbms newbies, who don't
> know much, if anything, about databases.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
>

On Thu, 2003-10-09 at 13:30, David Griffiths wrote:
> I also have to admit a bit of irritation reading this thread; there is a
> fair number of incorrect statements on this thread that, while not
> wrong, definately aren't right:
>
> "Speed depends on the nature of use and the complexity of queries.  If
> you are doing updates of related tables, ACID is of vital importance and
> MySQL doesn't provide it."
> MySQL has ACID in InnoDB.

Actually it only kinda sorta has acid.  As Jeff mentioned, and it can be
expanded upon, mysql has a nasty habit of transforming invalid data into
something that will insert into a table and not telling you about it. I
think Josh mentioned reports that it ignores some constraint
definitions.  And then theres the whole mixing MyISAM and InnoDB tables
completely breaks the ability to rollback transactions...

>
> "using InnoDB tables (the only way to have foreign keys, transactions,
> and row level locking for MySQL) makes MySQL slower and adds complexity
> to tuning the database"
> Adding this: "innodb_flush_method=O_DSYNC" to the my.cnf made InnoDB as
> fast as MyISAM in our tests. It doesn't turn off disk flushing; it's
> just a flush method that might work better with different kernels and
> drives; it's one of those "play with this and see if it helps"
> parameters; there are lots of those in Postgres, it seems. There are 10
> variables for tuning InnoDB (and you don't have to tune for MyISAM, so
> it's actually a six-of-one, half-dozen-of-the-other). Setup between the
> two seems to be about the same.

Well, I've yet to see MySQL benchmark themselves vs. the big boys using
InnoDB tables, I'm only guessing that it's because those tables are
slower. (Well, guessing and calling upon experience) Sure there may be
work arounds, but that does add a certain complexity. (Bonus for us,
PostgreSQL is just complex from the get go :-P )

>
> "PostgreSQL supports constraints. MySQL doesn't; programmers need to
> take care of that from the client side"
> Again, InnoDB supports constraints.
>

We've seen evidence it doesn't. If they've fixed this great. Of course
I'll quote from the mysql docs

"InnoDB allows you to drop any table even though that would break the
foreign key constraints which reference the table."

last I knew it did this silently and without warning. there are other
issues as well, so it's support is relative...

> "Transactions: We've been here before. Suffice to say, MySQL+InnoDB is
> almost there. Plain ol' MySQL doesn't have it, which tells you something
> about their philosophy towards database design."
> InnoDB supports transactions very nicely, has the equivalent of WAL, and
> one thing I really like: a tablespace (comprised of data files that can
> be spread around multiple hard drives), and in a month or so, InnoDB
> will support multiple tablespaces.
>

Just don't mix InnoDB and MyISAM tables together or you could end up in
a world of trouble... its unfortunate that this breaks one of the main
keys to building a DBMS, namely hiding implementation details from the
end users.

> Maybe the Postgres community needs an anti-FUD individual or two; people
> that know both databases, and can provide the proper information for
> answering questions like this.

Well, among the major advocacy folk we do have a mantra about no FUD,
but these are public lists so we cant really stop people from posting.
Of course this overlooks the fact that different people interpret
different information differently. (heh)  Take this quote I saw posted
in a non postgresql forum a while back: "MySQL doesn't fully support
subqueries" which of course created a slew of posts about FUD and
postgresql users being idiots. If course, when the posted responded back
with the question "Can mysql do subselects in the SELECT, FROM, and
WHERE clauses like postgresql, and nest subselects within those
subselects?" it stopped everyone in their tracks...

> A section in the docs would help as well.

In the docs no, on techdocs, maybe.

> Yes, I know many of the people advocating Postgres do not want to
> compare themselves to MySQL (but rather to Oracle, Sybase, DB2, etc) ,
> but the volume of responses on a thread like this indicates that the
> comparison is going to happen regardless. Better to nip it in the bud
> quickly than let it go on over 3-4 days.
>

It was due to the help of postgresql users that the following site has
become available: http://sql-info.de/mysql/gotchas.html
I'd suggest you look it over if your trying to evaluate a switch from
Oracle to MySQL.

And anyone is welcome, actually encouraged, to correct erroneous
information they see posted about any system on these lists. God bless
if you're willing to try and follow every list every day to watch for
these types of posts.


> One last observation: someone looking at both databases, reading those
> posts, might get a bad impression of Postgres based on the inconsistency
> and incorrectness of some of the statements made about MySQL. If a
> salesperson provides misinformation about a competitors product and you
> find out about it, that salesperson has most likely lost a customer.
>

Unfortunate that you'd attribute anyone who posts on these lists as a
sales person for postgresql...

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Scott,

> any chance of getting the perf.html file from varlena folded into the main
> documentation tree somewhere?  it's a great document, and it would
> definitely help if the tuning section of the main docs said "For a more
> thorough examination of postgresql tuning see this:" and pointed to it.

Actually, I'm working on that this weekend.

--
-Josh Berkus

______AGLIO DATABASE SOLUTIONS___________________________
                                        Josh Berkus
   Complete information technology     josh@agliodbs.com
    and data management solutions     (415) 565-7293
   for law firms, small businesses      fax 621-2533
    and non-profit organizations.     San Francisco

> Thanks for being considerate, thourough, and honest about your opinions.
> Particulary that you didn't simple depart in a huff.

Why would I depart in a huff? I was just trying to make a few objective
observations.

I really have no biases; I like what I've seen in MySQL, and I like alot of
the more Oracle-like
features in Postgres.

> > 4) we looked at MySQL first (we needed replication, and eRServer had not
> > been open-sourced when we started looking)
>
> I can't do anything about that, now can I?

My point was that it's since been open-sourced; it just means I've looked
longer at
MySQL, as it had replication when we started looking.

> Have you checked these pages?  They've been posted on this list numerous
> times:
> http://techdocs.postgresql.org
> http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
> http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html

Those are much more instructive; I'm curious - why aren't then in the
administrator's
section of the docs?

> We've been working on this on the advocacy list .... that is, giving an
> accurate listing of PostgreSQL features not posessed by MySQL (same for
> Oracle and DB2 as well, MySQL is just easier to start becuase we don't
have
> to worry about being sued).   I'd appreciate it if you'd take an interest
in
> that document and revise anything which is innaccurate or perjorative.

I might be able to provide some insight, but I've only been working with
MySQL for a month
or so (Oracle for about 8 years).

> > "PostgreSQL supports constraints. MySQL doesn't; programmers need to
> > take care of that from the client side"
> > Again, InnoDB supports constraints.
>
> Really?  This is news.   We did some tests on constraints on InnoDB, and
found
> that while they parsed, they were not actually enforced.    Was our test
in
> error?

You may have turned them off to load data? I've run into constraints when my
data-load script missed some rows in address_type. When it went to do the
address_list table, all rows that had the missing address_type failed, as
they
should. I saw no weakness in the constraints.


> > Maybe the Postgres community needs an anti-FUD individual or two; people
> > that know both databases, and can provide the proper information for
> > answering questions like this. A section in the docs would help as well.
> > Yes, I know many of the people advocating Postgres do not want to
> > compare themselves to MySQL (but rather to Oracle, Sybase, DB2, etc) ,
> > but the volume of responses on a thread like this indicates that the
> > comparison is going to happen regardless. Better to nip it in the bud
> > quickly than let it go on over 3-4 days.
>
> Would you care to volunteer?   We'd be glad to have you.

Maybe once all this database testing is done; it's extra work on top of an
already
heavy load (add a new baby, and free time goes right down the toilet).

I need to figure out my performance issues with Postgres, finish my
benchmark
suite, test a bunch of databases, argue with the CTO, and then start
migrating.

I'll be sure to post my results to the  pgsql-performance@postgresql.org
along with
the tests.

David.

On Thu, 9 Oct 2003, David Griffiths wrote:

> > > "PostgreSQL supports constraints. MySQL doesn't; programmers need to
> > > take care of that from the client side"
> > > Again, InnoDB supports constraints.
> >
> > Really?  This is news.   We did some tests on constraints on InnoDB, and
> > found that while they parsed, they were not actually enforced.    Was
> > our test in error?
>
> You may have turned them off to load data? I've run into constraints
> when my data-load script missed some rows in address_type. When it went
> to do the address_list table, all rows that had the missing address_type
> failed, as they should. I saw no weakness in the constraints.

It sounds like you talk about foreign keys only, while the previous writer
talkes about other constraints also. For example, in postgresql you
can do:

CREATE TABLE foo (
  x int,

  CONSTRAINT bar CHECK (x > 5)
);

and then

# INSERT INTO foo VALUES (4);
ERROR:  ExecInsert: rejected due to CHECK constraint "bar" on "foo"


I don't know MySQL, but I've got the impression from other posts on the
lists that innodb supports foreign keys only. I might be wrong though.

--
/Dennis

David Griffiths wrote:
>>Have you checked these pages?  They've been posted on this list numerous
>>times:
>>http://techdocs.postgresql.org
>>http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
>>http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html
> Those are much more instructive; I'm curious - why aren't then in the
> administrator's
> section of the docs?

Because they are much more recent. Not even 6 months old. And lot of people
differ on how exactly these tips applies. What goes in postgresql documentation
is fact and nothing but facts. Clearly such tips do not have any place in
postgresql documentation(At least in my opinion)

A pointer might get added to postgresql documentation. That's about it at the most.

  Shridhar

David Griffiths wrote:

> This is a timely thread for myself, as I'm in the middle of testing
> both databases as an Oracle replacement.
>
> As of this moment, I know more about MySQL (tuning, setup, features)
> than I do about Postgres. Not because I like MySQL more, but because
>
> 1) the MySQL docs are better (sorry - I found them easier to read, and
> more comprehensive; I had an easier time finding the answers I needed)
> 2) there are more web pages devoted to MySQL (probably because it has
> a bit more market share)
> 3) there are more books on MySQL at the bookstore (I haven't had a
> chance to pick up Bruce's book yet; it might be all the book I'd ever
> need)
> 4) we looked at MySQL first (we needed replication, and eRServer had
> not been open-sourced when we started looking)
>
> With regards to #1, I'd like to specifically mention tuning - the docs
> at http://www.postgresql.org/docs/7.3/static/runtime-config.html give
> a basic explanation of the different options, but much more is needed
> for tuning. I'm running into a problem with an update statement (that
> uses a select in a sub-query) in Postgres - it's taking  hours to run
> (the equiv, using a multi-table update statement in MySQL instead of a
> sub-query, takes all of 2 seconds). I'll be posting it later once I do
> more reading to make sure I've done as much as I can to solve it myself.


David,

I think you have valid observations.  And the issue regarding
replication has been quite a hot topic on occasion in the developer
lists.   I'm hoping at some point it would become part of the standard
PostgreSQL package; but point in time recovery, PITR, is needed as a
stepping stone to providing that functionality.

Have you attempted the multi table update inside of a transaction for
PostgreSQL yet and thus assuring the all of your updates are only
visible after the commit?   Depending on the design and the nature of
the updates, their could be a race condition if the updates on one table
are utilized by another process before the rest of the updates have
completed.

Sets of updates in a single transaction can improve performance as well.

>
> I really agree with this post:
>
> "I guess my point is simply this: instead of saying: "okay we use
> default settings that will run on _old_ hardware too" we should go for
> a little script that creates a "still save but much better" config
> file. There's just no point in setting SHARED_BUFFERS to something
> like 16 (what's the current default?) if the PC has >= 1 GB of RAM.
> Setting it to 8192 would still be save, but 512 times better...  ;-)
> (IIRC 8192 would take 64 MB of RAM, which should be save if you leave
> the default MAX_CONNECTIONS.)" It provides examples, and some real
> numbers to help someone new to the database take an initial crack at
> tuning. Remember, you're trying to compete with the big-guys (Oracle,
> etc), so providing info that an Oracle DBA needs is pretty critical.
> I'm currently at a complete loss for tuning Postgres (it seems to do
> things very differently than both Oracle and MySQL).
>
>
> I also have to admit a bit of irritation reading this thread; there is
> a fair number of incorrect statements on this thread that, while not
> wrong, definately aren't right:
>
> "Speed depends on the nature of use and the complexity of queries.  If
> you are doing updates of related tables, ACID is of vital importance
> and MySQL doesn't provide it."
> MySQL has ACID in InnoDB. I've found that MySQL is actually very fast
> on complex queries w/InnoDB (six tables, 1 million rows, two of the
> joins are outer-joins. In fact, I can get InnoDB to be almost as fast
> as MyISAM. Complex updates are also very very fast. We have not tried
> flooding either database with dozens of complex statements from
> multiple clients; that's coming soon, and from what I've read, MySQL
> won't do too well.
>
> "using InnoDB tables (the only way to have foreign keys, transactions,
> and row level locking for MySQL) makes MySQL slower and adds
> complexity to tuning the database"
> Adding this: "innodb_flush_method=O_DSYNC" to the my.cnf made InnoDB
> as fast as MyISAM in our tests. It doesn't turn off disk flushing;
> it's just a flush method that might work better with different kernels
> and drives; it's one of those "play with this and see if it helps"
> parameters; there are lots of those in Postgres, it seems. There are
> 10 variables for tuning InnoDB (and you don't have to tune for MyISAM,
> so it's actually a six-of-one, half-dozen-of-the-other). Setup between
> the two seems to be about the same.
>
> "PostgreSQL supports constraints. MySQL doesn't; programmers need to
> take care of that from the client side"
> Again, InnoDB supports constraints.
>
> "Transactions: We've been here before. Suffice to say, MySQL+InnoDB is
> almost there. Plain ol' MySQL doesn't have it, which tells you
> something about their philosophy towards database design."
> InnoDB supports transactions very nicely, has the equivalent of WAL,
> and one thing I really like: a tablespace (comprised of data files
> that can be spread around multiple hard drives), and in a month or so,
> InnoDB will support multiple tablespaces.
>
>
> To be fair, here are a few MySQL "bad-things" that weren't mentioned:
>
> 1) InnoDB can't do a hot-backup with the basic backup tools. To
> hot-backup an InnoDB database, you need to pay $450 US per database
> per year ($1150 per database perpetual) for a proprietary hot-backup tool
> 2) InnoDB can't do full-text searching.
> 3) I see alot more corrupt-database bugs on the MySQL lists (most are
> MyISAM, but a few InnoDB bugs pop up from time to time) - way more
> than I see on the Postgres lists.
> 4) There are some really cranky people on the MySQL lists; the
> Postgres lists seem to be much more effective (esp. with people like
> Tom Lane). Maybe it's because they get alot of dumb questions, as
> people unfamiliar with databases turn to MySQL first?
>
> Maybe the Postgres community needs an anti-FUD individual or two;
> people that know both databases, and can provide the proper
> information for answering questions like this. A section in the docs
> would help as well. Yes, I know many of the people advocating Postgres
> do not want to compare themselves to MySQL (but rather to Oracle,
> Sybase, DB2, etc) , but the volume of responses on a thread like this
> indicates that the comparison is going to happen regardless. Better to
> nip it in the bud quickly than let it go on over 3-4 days.
>
> One last observation: someone looking at both databases, reading those
> posts, might get a bad impression of Postgres based on the
> inconsistency and incorrectness of some of the statements made about
> MySQL. If a salesperson provides misinformation about a competitors
> product and you find out about it, that salesperson has most likely
> lost a customer.
>
> Anyway, I hope I haven't offended anyone - I'm not trying to troll or
> flame, but rather just give some constructive criticism from someone
> outside both the MySQL and Postgres camps.
>
> David
>