Re: Partitioning WIP patch

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

In response to

Responses

Browse pgsql-hackers by date

  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