Re: Partitioning WIP patch - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Partitioning WIP patch
Date
Msg-id 54EE7D92.5070901@lab.ntt.co.jp
Whole thread Raw
In response to Re: Partitioning WIP patch  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Partitioning WIP patch  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
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?

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

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

Thanks,
Amit




pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: contrib/fuzzystrmatch/dmetaphone.c license
Next
From: "Ratay, Steve"
Date:
Subject: Re: Unable to build pg_rewind