Re: PostgresSQL 7.x Oracle8 Comparison - Mailing list pgsql-general

From tatebll@aol.com (Bill Tate)
Subject Re: PostgresSQL 7.x Oracle8 Comparison
Date
Msg-id cb4ba455.0110300513.33a9e365@posting.google.com
Whole thread Raw
In response to PostgresSQL 7.x Oracle8 Comparison  (nickh@one.net (Nick))
List pgsql-general
nickh@one.net (Nick) wrote in message news:<3893f63a.0110290832.7ff5e662@posting.google.com>...
> Currently, my solution is to develop a system based on Red Hat 7.1
> using the Red Hat PostgreSQL 7.1 solution.  My only constraint is
> money.  And I'm trying to put this together way under budget (hence my
> reasoning for giving PostgreSQL 7.1 serious consideration).
>
> If anyone could direct me to a comparsion site, so I can evaluate
> other options, or give me some advise, it would be most appreciated.
>
> Thanks for the help.
>
> Nick
Nick -
There is a recent posting that I saw when I used google to search on
PG and scalability.  The performance tests were run by a company out
of VA for the now defunct :>( great bridge.  If the results are
credible, then they are encouraging, particularly with respect to
scalability of concurrent users.

Assuming all things being equal (not generally), I would strongly
advise that whatever your choice, you use something like OpenSTA if
you want to thoroughly test your application and backend for
performance.  Their Oracle DB instance is struggling because of a
highly denormalized DB schema. Oracle could easily handle this app,
but a bad design is still a bad design.

An anecdotal example -

A close friend of mine works for a company that is currently running
PG with Red Hat on a DEC alpha.  Presently the DB server is handily
pushing over 1/2 MILLION transactions per minute on that server.  The
application is geared towards the telecomm industry which is obviously
transaction intensive.  He has several tables in this PG database
instance that contain over 50 million records EACH.  Uptime and
stability have been excellent.  He has has no reservations about
whether PG is ready for prime time.  From a transaction DB
perspective, PG fulfills the core requirements.  IMHO, there are a
handful of DBA-related features that I think PG needs to address,
which I'm to understand are coming, but none of them would stop me
from using PG and implementing some kind of work around should it be
necessary.

One other thing of note.
I spend most of my time programming in Java, C++ and Python, the
latter being my favorite, but I would have to give a thumbs up to
PL/SQL (Oracle) and PL/pgSQL (PG).   Since most of the work I do deals
with DB backends, there is a lot to like about these extensions for
SQL. The package feature (Oracle's OO enhancement) I'm to understand
is coming for PG.  While packages do not conform with the OO "purists"
view, I can tell you I would have loved to have had that capability on
some of my past work.  Since the syntax of PL/SQL and PL/pgSQL are
virtually identical in most respects, the experienced gained from
learning one is largely transferable. That could be a huge plus when
you think about the heterogeneous environment that often exists wrt DB
server installs.

One very nice feature of Oracle is its xml capabilities.  This is
going to be a crucial technology for any DB vendor.  The current
offerings from Apache (XALAN, XERCES and SOAP) are well-suited to
incorporating into DB intensive applications.  It is not necessary
that XML capabilities be embedded in the DB api, in fact, it may be
preferable to not tie oneself so closely.  Again, PG does not pose any
impediment to implementing this technology.

Hope this helps.
Bill

pgsql-general by date:

Previous
From: Lixin Zhou
Date:
Subject: Re: create function question
Next
From: Stephan Szabo
Date:
Subject: Re: create function question