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.1399826...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
