Re: [GENERAL] Re: Is PostgreSQL ready for mission critical applications? - Mailing 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.
I have solved all of the problems I have encountered through my light usage
of PostgreSQL.  The problems I refer to are problems I read about in here
for example when users say they have corrupt indexes and the suggested
solution is to rebuild all the indexes (which is not easy to do i.e. one
click of the mouse, or a problem that should occur so often)

> 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.

Although I do see this happen all of the time...it still is a deficiency
that makes the database that much harder to learn and use...

> > 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.
I think the concept of user friendly design is universal.  There should be
one button in the middle of the screen you push and everything is done for
you :)  (refer to technical support if you need to know more :)

> > 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")
Database administration is not just system maintenance.  It is also
designing and maintaining tables, stored procedures, triggers etc ...

> > 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.
I havent been though the documentation in quite a while.  But I remember
wanting to know allt he files that were installed for PostgreSQL and where
they were located as well as what each file is used for, how the system was
affected by abnormal shutdowns, a list of all the possible error msgs
generated and the steps to recover/correct the problems, file buffer
optimization, transaction buffer optimization, disk space usage for tables
and indexes and how to calculate them, system tables and what each field
meant and when they were updated, how to turn on system metrics for
transactions, what are the pros and cons of potential backup procedures;how
are they done...  Those were just a few questions I had back when.  Never
found the answers back then...

> > 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?
Same as before...I have read numerous responses that state that the only way
to resolve a problem is to go to tape backups and restore....I personally
have never had to do it (Thank God)

> > 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?
Oracle is under $10000 if u dont ask for the unlimited Internet users
version ;)

> > 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.
That brings up the differences in views on what is a mission critical
system.  I see it as a 24x7 system that has thousands of transactions daily
in which the system cannot be down in case of emergency for more than 15
minutes and in case of scheduked down time less than 5 minutes if not at
all.