From: | Jan Wieck <janwieck(at)yahoo(dot)com> |
---|---|
To: | Michael Devogelaere <michael(at)digibel(dot)be> |
Cc: | Jan Wieck <janwieck(at)yahoo(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, Justin Clift <justin(at)postgresql(dot)org>, PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL crashes with Qmail-SQL |
Date: | 2002-01-25 04:35:15 |
Message-ID: | 200201250435.g0P4ZFC01727@saturn.janwieck.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Devogelaere wrote:
> >
> > 4. Instead of investigating what the problem is, PostgreSQL
> > was reported to *Crash*.
> Yes: it *crashed*. Since i disabled all debugging i cannot help you
> with investigating this problem. I hope i won't get the death penalty
> for this ;)
> >
> > It cannot get any more obvious.
> Please elaborate.
I hope you don't take any of my comments personal. Because
they are not! It is just that I am tired and bored of these
every so often repeated MySQL optimized "benchmarks".
I see a clear difference between a database server process
crash and a disabled service caused by misbehaving sysadmin
scripts and/or bad service because of contra-optimized client
behaviour.
This is exactly the same style of reporting crashes or bad
performace, the MySQL folks have practiced for years. I
remember creating and dropping tables a couple thousand
times, then VACUUM with a user that doesn't have permissions
to vacuum system catalogs, and report bad performance because
the system cache got successfully screwed up ... there was
even a comment in the script saying "this makes Postgres
slow" ... haha. Other reported *crashes* have been core
dumps of the test-scripts, because Postgres dealt with datums
bigger than the perl-client was able to swallow ... well, the
test driver just reported a crash, not exactly where and why,
does that really matter? MySQL shows success and Postgres
does not, that's what counts.
The lowest level still accepted Transaction Processing
Council Benchmark, TPC-C, can be implemented with a SUT using
MySQL. Do it using LAMP, if you want to learn what a database
crash is ;-)
There is a good reason why TPC has abandoned the TPC-1, TPC-A
and TPC-B benchmarks. They are "too simple" to be of any
meaning for benchmarking purposes these days. Yet all the
stuff this huge crowd of MySQL-Lemmings is constantly
babbling about is even more simple than that! They all have
their reasons, the TPC members (basically all serious RDBMS
vendors) on one side as well as the MySQL folks on the other.
As a matter of fact, the MySQL folks are alone with their
point of view that "beeing fastest on a single-table-select"
is the most important criteria for a relational database
management system. And as another matter of fact, Lemmings
get what Lemmings deserve, MySQL!
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-01-25 04:38:22 | Backend shutdown time? |
Previous Message | Bruce Momjian | 2002-01-25 04:33:52 | Re: RFD: schemas and different kinds of Postgres objects |