Re: Sponsoring enterprise features - Mailing list pgsql-hackers

James,

> I'm not sure what Oracle has to do with any of this.  If I wanted to use
> Oracle, I would buy Oracle. 

Good.  Your original post, which appeared to propose carbon-copying a number 
of features from Oracle -- I didn't necessarily read it that way, but several 
other people did, including some of the developers you will want to recruit.    
You are not the first person to put forward some of these ideas, and your 
predicessors tended to follow the line "but if Oracle does it that way, it 
must be good."   So it's a knee-jerk reaction thing.

AFAIK, Tom was just warning you that your feature proposals need to be backed 
by arguments/evidence that they will actually improve performance or expand 
capabilities for PostgreSQL in some meaningful way.   You seem prepared to do 
that, so we shouldn't have any disagreements in that way.

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

heap management == table partitioning?

I'm a little unclear, personally, about what can be accomplished through table 
partitioning that we can't currently do through partial indexes and inherited 
tables, especially after Gavin finishes his tablespaces patch (btw, Gavin 
could use sponsorship on that one, I think).  Can you make your case to 
me/the list?   So far, the only arguments we've gotten on this list have been 
of the "Oracle does it that way" variety so it'd be interesting to see 
something concrete.

Now, query partitioning is something I think everyone is interested in, and 
would very much like to see someone implement.  

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

Cool.   I look forward to seeing the fruits of this effort.

From my perspective, the other "oracle-killer" that we're missing includes 
some isolated but difficult improvements in the Query Planner necessary to 
pass the TPC benchmarks.   I'd be happy to discuss those as well, if you 
like.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco