Re: [GENERAL] Benchmarks - Mailing list pgsql-general

Hi,

It was good that I have chanced upon your mail.

I'm currently implementing a very high performance reliability application
using postgres.
I'm risking lots of debate and criticism on what I have to say. This is
based on practical experience. I have decent experience is using DB2 and a
reasonable experience using Oracle and SQL-Server.

My opinion is as follows.
I wouldn't look at most benchmarking numbers for the app. you are
programming. We are currently facing some performance issues which I'm
sorting out. I was involved in a major benchmarking exercise about 3 years
back where we did exactly what you are looking for.... Results - Oracle and
Sybase and off all surprises even Ingres (which is now extinct) delivered
results which were quite indistingushable. My experience shows that if you
want to extract the juice out of the platform it all lies in the DB design
and coding !! It has been repeatedly proved with every DB I have worked on,
including Postgres.

Having said that... Let me stick my neck out and list some of the problems
we have been facing with Postgres
a) When faced with very heavy transaction loads postgres may crash !! With
great effort and about 3 weeks of full time effort on my part and also
thanks to the pg user community, I hope to have fixed it. I'm still awaiting
further testing before I write to this mailing list all details regarding
what we went thru'.
b) There are quite a few things which you'd take for granted in other DBs
which postgres does not have. Quite late in the day I was shocked to find
that postgres does not have roll-forward transaction logging. They have
Multi-version concurrency control and rollback support but you can't restore
a backup and play logs !!
c) Another issue which rankles me a lot is that postgres maintains different
tables in different files. I remember lots of debate on this issue between
1993 and 95 and most DBMS's have settled down into having all tables within
their own file structure... presumably to take over buffering and other
mechanisms from the OS onto themselves. I have even read literature where
Oracle and DB2 allow U to create DB's on raw UNIX partitions. I'm not sure
whether they are still used.
d) Postgres manual recommends a nightly vacuum. I read this also a bit late.
This is equivalent of rebuild database. While this is in progress all other
clients wait for vacuum release locks. This is really a handicap for a 24x7
app.

Also, Please.... consider DB2. They are vastly underrated. On the mainframe
it is just fantastic. I would like to extrapolate this experience. They are
6 month delayed in features as compared to Oracle... but I have found it to
be extremely reliable at a very competitive price. I just hope they have not
screwed it up on Linux.

At the same time.... postgres would be a great choice when you have
a) hardware  resource constraints
b) Less money to buy software
c) your app is not mission critical and 24x7.

Bye,

Murali

-----Original Message-----
From: Michael Cornelison <mcornel@magnify.com>
To: pgsql-general@hub.org <pgsql-general@hub.org>
Date: 05 January 2000 13:18
Subject: [GENERAL] Benchmarks


>I don't know if this is an already talked about issue. If it is I apologize
>in advance.
>
>I getting ready to gear up for a major database project.
>I am considering pgsql and oracle on a Intel/Linux platform.
>I did see the comparison of the different feature of all the databases, but
>that is not exactly what I need.
>I was really wondering if there are any existing benchmarks between the
two.
>like the number of selected records/second for a narrow table (10-20
>columns) and as well for a wide table (150+ columns)
>I would also be interested in the local vs. networked client benchmarks as
>well.
>I would also be interested in the speed of the inserts on similar tables.
>
>My projects is going to have very heavy traffic (some web, some data entry,
>and some real time data) and performance is going to be key.
>
>I just wanted to see if anyone has done anything like this before I attempt
>it. It would help minimize some of my work and/or reinforce any of my
>fining.
>
>Thanks
>Michael Cornelison
>
>
>
>
>************
>