Re: [GENERAL] Re: Is PostgreSQL ready for mission critical applications? - Mailing list pgsql-general

From Peter Eisentraut
Subject Re: [GENERAL] Re: Is PostgreSQL ready for mission critical applications?
Date
Msg-id Pine.LNX.4.20.9911231548370.352-100000@localhost.localdomain
Whole thread Raw
In response to Re: [GENERAL] Re: Is PostgreSQL ready for mission critical applications?  ("Kane Tao" <death@solaris1.mysolution.com>)
List pgsql-general
How about isolating some of these problems and solving them? Or if you
don't have the time/skills to do that, at least develop a detailed plan
how it should work. I am not trying to be arrogant here, but this project
depends on people finding things that annoy them and then fix them. That's
how I ended up here.

In particular documentation issues are more prone to be neglected because
the core developers are of course extremely familiar with everything and
also mostly have other things to do. (No offense to Thomas -- great work.)
It takes no programming skills to update the documenation, and if you
don't know SGML/DocBook, we're here to help.

On 1999-11-21, Kane Tao mentioned:

> 1)  It requires a VERY skilled DBA in both Unix and PostgreSQL

Granted, the installation process receives critique all the time. How
would you like it to work? What parts are too complicated? If they only
*appear* to be so, then this is a documentation deficiency, otherwise we'd
need to think about it.

> 2)  There are few tools that make for ease of development and
> administration.

Personally, I am under the impression that there is not a whole lot of
administering to do, which is Good. Regarding ease of development, the
interfaces we offer are IMHO just as good as other DBMS' offer, but we're
not in the business of providing toolkits such as Zope. If less third
parties choose to support us, that sucks, but it's not an argument against
PostgreSQL itself. (cf. "<some_free_os> is inferior because there are no
'productivity' apps available for it")

> 3)  Documentation is no where near as detailed or all encompassing as a
> database like Oracle.

Although I usually find what I need, see 2nd paragraph.

> 4)  There are certain instances when the database requires a rebuild from
> scratch or tape that are not related to hardware failure or disk corruption.

Huh?

> .5)  There are no transaction logs or redo logs that allow you to recover
> the database to a point in time or handle hot online backups.

Point granted. But it's coming.

> 6)  It does not scale up to multi processor/multi threading very well (As I
> understand it).

I don't understand this area too well either, but is there *anything*
below $10000 that scales to multiprocessors well?

> 7)  A vacuum has to be run often (at a regular interval) taking up valuable
> system resources...locking tables and sometimes just failing utterly.

Not really. Sunday morning at 4 should suffice unless you run the hottest
thing on the Net.

    -Peter

--
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] old releases of PostgreSQL ?
Next
From: marten@feki.toppoint.de
Date:
Subject: Re: [GENERAL] Re: Is PostgreSQL ready for mission criticalapplications?