From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Partitioning WIP patch |
Date: | 2015-02-26 01:57:38 |
Message-ID: | 54EE7D92.5070901@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Ratay, Steve | 2015-02-26 02:34:25 | Re: Unable to build pg_rewind |
Previous Message | Andrew Dunstan | 2015-02-26 01:36:49 | Re: contrib/fuzzystrmatch/dmetaphone.c license |