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: