On Wed, Dec 10, 2014 at 12:33 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Tue, Dec 9, 2014 at 11:44 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> On 12/09/2014 12:17 AM, Amit Langote wrote:
>> >> Now if user wants to define multi-column Partition based on
>> >> > monthly_salary and annual_salary, how do we want him to
>> >> > specify the values. Basically how to distinguish which values
>> >> > belong to first column key and which one's belong to second
>> >> > column key.
>> >> >
>> > Perhaps you are talking about "syntactic" difficulties that I totally
>> > missed in my other reply to this mail?
>> >
>> > Can we represent the same data by rather using a subpartitioning scheme?
>> > ISTM, semantics would remain the same.
>> >
>> > ... PARTITION BY (monthly_salary) SUBPARTITION BY (annual_salary)?
>>
>
> Using SUBPARTITION is not the answer for multi-column partition,
> I think if we have to support it for List partitioning then something
> on lines what Josh has mentioned below could workout, but I don't
> think it is important to support multi-column partition for List at this
> stage.
>
Yeah, I realize multicolumn list partitioning and list-list composite partitioning are different things in many
respects.And given how awkward multicolumn list partitioning is looking to implement, I also think we only allow single
columnin a list partition key.
>> ... or just use arrays.
>>
>> PARTITION BY LIST ( monthly_salary, annual_salary )
>> PARTITION salary_small VALUES ({[300,400],[5000,6000]})
>> ) ....
>>
>> ... but that begs the question of how partition by list over two columns
>> (or more) would even work? You'd need an a*b number of partitions, and
>> the user would be pretty much certain to miss a few value combinations.
>> Maybe we should just restrict list partitioning to a single column for
>> a first release, and wait and see if people ask for more?
>>
>
> I also think we should not support multi-column list partition in first
> release.
>
Yes.
Thanks,
Amit