Re: database contest results

mdean wrote:

> Jeff Davis wrote:
>
>> On Wed, 2006-08-30 at 00:10 +0200, Andreas Pflug wrote:
>>
>>
>>
>>
>
> Guys, what I need is alternative benchmark data, where postgresql
> comes out better on standard assumptions, etc. than i this example
> Can this be done?
> Michael
>
>
>
I think it can be done, it's just a lot of work. At a minimum, I'd say
that:
1) Reliability of final configuration needs to be tested with a "pull
the plug" test, probably repeated a number of times. If the database
doesn't survive this then it is disqualified as not meeting minimum
requirements.

2) Multi-threaded access to the database is needed- at least dozens of
threads doing asynchronous changes (updates, inserts, deletes, selects)
to the database using transactions. Non-transactional databases need
not apply.

3) The database needs to be tuned by people who actually know how to
tune the database. This is the classic "Postgres is slow!" mistake-
they run a default configuration. This also means the clients run on a
different machine, and the specs of the database machine are a)
reasonable, and b) known to the tuners, so they can actually use the
capabilities of the machine. At this point, I'd say a reasonable lower
bound would be a 64-bit CPU, at least 4G of memory, and 6-8 SATA drives
in a RAID 1+0 configuration.

Note that in any sort of "real" environment, which includes a small
webserver app that I actually care about, these requirements will
reflect reality. Sooner or later the plug is going to get pulled on my
database- power outage, the magic smoke being released from some
hardware, something will happen which will make the database die
uncleanly, and need to recover from it. And sooner or later I'm going
to have more than 1 person accessing the database at a time- at which
point transactions will be a lifesaver (as a side note, this is why I
picked Postgres over Mysql). Even more so, when performance is most
important is when I have lots of people hitting the DB simultaneously-
my website just got slashdotted or what have you. And finally, no
matter which database I end up picking, I'm going to put some time into
learning that databases, including how to tune that database.

The problem here is the cost- both in hardware (we're talking ~$3-4K for
the DB server alone), but even more so in time. Time to set up the
database, time for the knowledgable people to come out of the woodwork
and help you configure the database (and possibly the application), time
to unplug each database multiple times, etc. Not even a long weekend is
enough time, you're looking at weeks, if not months. More time than
most journalists are willing to invest just to write a "Database
performance shoot out! Details inside!" article.

Brian