Re: Sponsoring enterprise features - Mailing list pgsql-hackers
From | James Rogers |
---|---|
Subject | Re: Sponsoring enterprise features |
Date | |
Msg-id | 1069437067.13686.32.camel@localhost.localdomain Whole thread Raw |
In response to | Re: Sponsoring enterprise features (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
On Thu, 2003-11-20 at 22:20, Tom Lane wrote: > It should be noted that "because Oracle does it that way" is a > guaranteed nonstarter as a rationale for any Postgres feature proposal. A method of doing something is not a "feature"; making something possible that couldn't be done before is a "feature". I don't really care how Oracle does something, though I am cognizant of *why* Oracle does something. s/Oracle/DB2/, and little changes. > There are enough differences between Postgres and Oracle that you will > need to do significant investigation before assuming that an Oracle- > based feature design is appropriate for Postgres. Aside from technical > differences, we have fundamentally different priorities --- one of which > is simplicity of administration. You'll get no buyin on proposals that > tend to create Oracle-like difficulties of installation and tuning. I'm not sure what Oracle has to do with any of this. If I wanted to use Oracle, I would buy Oracle. The thing is, I'm intimately familiar with Oracle and there are a lot of things I despise about Oracle as a consequence of this familiarity. The features I'm talking about can be added to any reasonable database engine, and are generically supported features (or "enterprise" add-ons) in virtually all large commercial databases. As I stated previously, I/we are interested in adding features for managing very large tables and working sets, and making Postgres scale in general for these kinds of databases (currently, it does not). These kinds of features will be important for enterprise users, particularly ones interested in migrating from Oracle/DB2/SQLServer/etc, and would be invisible to people that don't need them. This is a matter of adding important functionality that can be supported by any reasonable database engine. In a nutshell, the features on my short list are all about heap management (e.g. partitioning). This is really important when databases reach a certain size, but something for which Postgres has almost no support. >From a large-scale enterprise database standpoint, heap management is almost as important a capability as replication. Replication is being aggressively worked on, heap management is not and so we are interested in making sure this part gets developed. When PostgreSQL has this, there will be little reason for anyone to use the big commercial database-du-jour. I don't care how its implemented specifically, just as long as it is in there, and there is no technical reason that it couldn't be implemented per previous discussions. I've gotten the green light (and many responses from people interested in doing it) to start writing up RFQs for specific features, which I will post to the pg-hackers list. It is all stuff previously determined to be doable within the current PostgreSQL framework, and just requiring some work that my company is willing to help pay for. Cheers, -James Rogersjamesr@best.com
pgsql-hackers by date: