Re: On partitioning

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>
Cc: 'Robert Haas' <robertmhaas(at)gmail(dot)com>, 'Andres Freund' <andres(at)2ndquadrant(dot)com>, 'Alvaro Herrera' <alvherre(at)2ndquadrant(dot)com>, 'Bruce Momjian' <bruce(at)momjian(dot)us>, 'Pg Hackers' <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: On partitioning
Date: 2014-12-09 18:14:01
Message-ID: 54873BE9.2090802@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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)?

... 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?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2014-12-09 18:18:50 Re: moving from contrib to bin
Previous Message Alvaro Herrera 2014-12-09 17:41:46 logical column ordering