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