Re: Partitioning WIP patch - Mailing list pgsql-hackers

On 2/26/15 3:09 AM, Amit Langote wrote:
>> Yes. If it helps, the exact use-case I have in mind is using list-based
>> >partitioning + additional columns in some/all children (different
>> >between children). For example, if you need to track different types of
>> >customer payment methods, you'd have a payment parent table, a list
>> >partition for credit & debit cards, a different list partition for bank
>> >accounts, etc.
>> >
>> >The reason I'd like to do this with partitioning vs plain inheritance is
>> >presumably as we build out partitioning we'll get very useful things
>> >like the ability to have FKs to properly partitioned tables. Insert
>> >tuple routing could also be useful.
>> >
> Unless I'm missing something again, isn't allowing partitions to have
> heterogeneous rowtypes a problem in the long run? I'm afraid I'm
> confused as to your stand regarding inheritance vs. new partitioning. To
> be specific, children with heterogeneous schemas sounds much like what
> inheritance would be good for as you say. But then isn't that why we
> have to plan children individually which you said new partitioning
> should get away from?

Apologies if I haven't been clear enough. What I'd like to see is the 
best of both worlds; fast partitioning when not using inheritance, and 
perhaps somewhat slower when using inheritance, but still with the 
features partitioning gives you.

But my bigger concern from a project standpoint is that we not put 
ourselves in a position of supporting something that we really don't 
want to support (a partitioning system that's got inheritance mixed in). 
As much as I'd personally like to have both features together, I think 
it would be bad for the community to go down that road without careful 
thought.

>>> >>With explicit partitioning, shouldn't we go in direction where we remove
>>> >>some restrictions imposed by inheritance (think multiple inheritance)? I
>>> >>recall a link Alvaro had started the discussion with think link to a
>>> >>Tom's remark about something very related:
>>> >>
>>> >>http://www.postgresql.org/message-id/1598.1399826841@sss.pgh.pa.us
>> >
>> >That post looks like Tom figured out a way to eliminate a problem that
>> >hurts inheritance, so that's good.
>> >
>> >My fear is that at some point we'll hit a problem with partitioning that
>> >we can't solve in the inheritance model. If we allow inheritance
>> >features into partitioning now we'll painted into a corner. If we
>> >disallow those features now we can always re-enable them if we get to
>> >the point where we're in the clear.
>> >
>> >Does that make sense?
> Yes, it does. In fact, I do intend to keep them separate the first
> attempt of which is to choose to NOT transform a PARTITION OF parent
> clause into INHERITS parent. Any code that may look like it's trying to
> do that is because the patch is not fully baked yet.

Ok, good to know. That's why I was asking about ALTER TABLE ADD COLUMN 
on a partition. If we release something without that being restricted 
it'll probably cause trouble later on.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com