Re: PostgreSQL a slow DB?

> Except when it doesn't work. It's a completely non-scientific method
> of determining answers, and has *enormous* bias due to ignorance.
>

That has been my question all along...
Instead of "beating" people down when they (and others) have a concern,
rather it's real or not, you guy have to put real concrete information and
solutions out there to counter these misconceptions.

My co-workers and I believe that PG is slow.
A way of helping this is by providing a solution to configuring the database
to work the best for a person setup, or give them some general parameters to
look into.

The impression of PG being slow will not be solved by statements such as
"Some people believe Elvis is still alive."

> Traditionally, MySQL(tm) has had a lot of loosely-done, unanalyzed
> "benchmarketing" done where the tests done are those that can be done
> without any real design. MySQL(tm) probably still has some advantages in
> performance when the usage patterns combine:
> a) Single user access
> b) A series of simple queries expected to access one or two tuples
> c) Low system load
> d) A pattern that discourages transaction usage
>
> Any "designed in 15 minutes" sort of benchmark is quite likely to fit
> into this.
>
> "Let's go insert 20000 rows into a table, and then run 20000 queries
> that each pull one of those rows, and see how long it takes."
>
> It has been common for MySQL(tm) with MyISAM to win these sorts of
> "contests" that are obviously biased to what it was designed to do
> well, as a thin veneering of SQL on top of a B-Tree ISAM library.
>
> Vary any of those assumptions, and the results change pretty
> substantially.
>
> -> MyISAM doesn't scale at all well with many concurrent updaters,
> whereas PostgreSQL, for instance, handles that extremely well.
> -> No transaction overhead goes along with no transactional integrity;
> you can't expect consistent results to come back without your
> application being very careful to never cross any of the
> "semantic lines" that will make MySQL(tm) eat your data.
> -> There's an interesting paucity of benchmarks involving the newer
> "transactional storage engines" (and presumably there never will
> be any, as they are now all owned by "no, you can't publish that
> benchmark" Oracle). Indications are that the InnoDB engine
> drops performance by a fair bit, particularly any time there is
> need to roll back transactions...

I see and hear this kind of stuff all the time.
Every company has a boilerplate answer to why the competition is worse.

So how does a potential user figure out which is better...

More people know of MySQL and MySQL is assoicated with speed.
Rather it's real or not, it doesn't matter. MySQL has got mindshare.

PG is assoicated to slow, complex, hard to use and arrogant support.

Stop with the "My daddy can beat up your daddy" mentality and show us HOW to
setup
PG to be fast.
That why, we can ALSO be a voice to prove that PG is fast and not complex
and eventually disspell the notion that PG is a slow database.

Thanks