On 2/25/15 7:57 PM, Amit Langote wrote:
On 26-02-2015 AM 10:31, Jim Nasby wrote:
On 2/25/15 7:24 PM, Amit Langote wrote:
Does ALTER TABLE parent_monthly_xxxxx_201401 ADD COLUMN foo still
operate the same as today? I'd like to see us continue to support that,
but perhaps it would be wise to not paint ourselves into that corner
just yet.
Nothing prevents that from working, at least at the moment.

Ok, but is that what we really want? If we release it that way we'll be
stuck with it forever.


AIUI, as far as we stay with a design where partitions (children) are
individually planned, that might be OK. But, I guess things will get
more complicated. I think the role of a parent in planning would remain
limited to drive partition-pruning. Am I missing something?

Isn't the point of adding explicit partitioning to make it faster than plain inheritance? Presumably as part of that we'll eventually want to NOT plan children individually.

I would certainly prefer that we support the capabilities of inheritance
along with partitioning (because in some cases you want both). But it's
going to limit what we can do internally.

Just to clarify are you referring to inheritance relationship between a
partitioned table and partitions?

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.

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

Reply via email to