Re: Sponsoring enterprise features

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 Rogers
jamesr(at)best(dot)com