On Tue, Dec 9, 2014 at 11:44 PM, Josh Berkus <j...@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.
> ... 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.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
