Subject: Re: Declarative partitioning
To: Simon Riggs <simon@2ndQuadrant.com>
References: <55D3093C.5010800@lab.ntt.co.jp>
 <WM!d7710f5363855cdb19d569b89c9c5e583742def1a8442d29ccee7f2591bfe40e9b26d6d9500448c2078cac09dedcf224!@asav-3.01.com>
 <55D36BFA.7080004@agliodbs.com>
 <CANP8+jLDBxfndrXpwuoqsB8iQN1tJu14shd68+v-KnBnnpGLXw@mail.gmail.com>
 <WM!952c85ac5038044c064918d1f182b019f01a36b62a9fd1111248789b2e3dc7b2dc3d53e4f18a4b23efd54ae06d6c1eb5!@asav-3.01.com>
 <55D4E2D0.3010906@agliodbs.com> <55D5997C.8040405@lab.ntt.co.jp>
 <CANP8+jLsxoXEUoL7J5gJGN=pbRf8xeZuqnfAEEO2D4zfsmX3Jg@mail.gmail.com>
Cc: Josh Berkus <josh@agliodbs.com>, Pg Hackers <pgsql-hackers@postgresql.org>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Message-ID: <55D5A22C.6040304@lab.ntt.co.jp>
Date: Thu, 20 Aug 2015 18:47:24 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: 
 <CANP8+jLsxoXEUoL7J5gJGN=pbRf8xeZuqnfAEEO2D4zfsmX3Jg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 2015-08-20 PM 06:34, Simon Riggs wrote:
> On 20 August 2015 at 10:10, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
> wrote:
> 
>> On 2015-08-20 AM 05:10, Josh Berkus wrote:
>>>>    PARTITION BY RANGE ON (columns) INCREMENT BY (INTERVAL '1 month' )
>>>> START WITH value;
>>>
>>> Oh, I like that syntax!
>>>
>>> How would it work if there were multiple columns?  Maybe we don't want
>>> to allow that for this form?
>>>
>>
>> Yea, we could simply restrict it to the single column case, which does not
>> sound like a major restriction.
>>
> 
> PARTITION BY ...
> SUBPARTITION BY ...
> 
> We should plan for that in the way we develop the internals, but full
> support can wait until later patches.
> 

At the moment, a form of SUBPARTITION BY is to allow PARTITION BY in a
partition definition. But I can see that may not be what people would expect.

> My view has long been that the internals are they aspect here, not the
> syntax. We need to be able to have a very fast partition-selection
> mechanism that can be used in the planner or executor for each tuple.
> Working backwards, we need a relcache representation that allows that, and
> a catalog representation that allows that and syntax to match.
> 

Agreed.

Thanks,
Amit


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers