Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Xzpkg-0004Ma-5h for pgsql-hackers@arkaria.postgresql.org; Sat, 13 Dec 2014 16:41:06 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Xzpkf-00064e-Ez for pgsql-hackers@arkaria.postgresql.org; Sat, 13 Dec 2014 16:41:05 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Xzpke-00064X-3t for pgsql-hackers@postgresql.org; Sat, 13 Dec 2014 16:41:04 +0000 Received: from quark.amimatica.com ([213.27.130.92]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Xzpka-0007wL-K0 for pgsql-hackers@postgresql.org; Sat, 13 Dec 2014 16:41:03 +0000 Received: from vortex.hq.g4ii.com (182.Red-88-26-239.staticIP.rima-tde.net [88.26.239.182]) by quark.amimatica.com (Postfix) with ESMTPA id 0004F521; Sat, 13 Dec 2014 17:40:57 +0100 (CET) Message-ID: <548C6C17.40602@adv-solutions.net> Date: Sat, 13 Dec 2014 17:40:55 +0100 From: =?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.0 MIME-Version: 1.0 To: Amit Langote , 'Robert Haas' CC: 'Amit Kapila' , 'Andres Freund' , 'Alvaro Herrera' , 'Bruce Momjian' , 'Pg Hackers' Subject: Re: On partitioning References: <20140829155607.GF7705@eldon.alvh.no-ip.org> <066501cffd52$3d919390$b8b4bab0$@lab.ntt.co.jp> <032601d00471$ea6f4280$bf4dc780$@lab.ntt.co.jp> <04da01d00917$2dde1010$899a3030$@lab.ntt.co.jp> <015b01d00eab$56d37700$047a6500$@lab.ntt.co.jp> <002d01d01359$290cb4a0$7b261de0$@lab.ntt.co.jp> <007b01d015c6$373c21e0$a5b465a0$@lab.ntt.co.jp> In-Reply-To: <007b01d015c6$373c21e0$a5b465a0$@lab.ntt.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 12/12/2014 05:43 AM, Amit Langote wrote: > [snip] > In case of what we would have called a 'LIST' partition, this could look like > > ... FOR VALUES (val1, val2, val3, ...) > > Assuming we only support partition key to contain only one column in such a case. Hmmm…. [...] PARTITION BY LIST(col1 [, col2, ...]) just like we do for indexes would do. and CREATE PARTITION child_name OF parent_name FOR [VALUES] (val1a,val2a), (val1b,val2b), (val1c,val2c) [IN tblspc_name] just like we do for multi-valued inserts. > In case of what we would have called a 'RANGE' partition, this could look like > > ... FOR VALUES (val1min, val2min, ...) TO (val1max, val2max, ...) > > How about BETWEEN ... AND ... ? Unless I'm missing something obvious, we already have range types for this, don't we? ... PARTITION BY RANGE (col) CREATE PARTITION child_name OF parent_name FOR [VALUES] '[val1min,val1max)', '[val2min,val2max)', '[val3min,val3max)' [IN tblspc_name] and I guess this should simplify a fully flexible implementation (if you can construct a RangeType for it, you can use that for partitioning). This would substitute the ugly (IMHO) "VALUES LESS THAN" syntax with a more flexible one (even though it might end up being converted into "less than" boundaries internally for implementation/optimization purposes) In both cases we would need to allow for overflows / default partition different from the parent table. Plus some ALTER PARTITION part_name TABLESPACE=tblspc_name The main problem being that we are assuming named partitions here, which might not be that practical at all. > [snip] >> I would include the noise keyword VALUES just for readability if >> anything. +1 FWIW, deviating from already "standard" syntax (Oracle-like --as implemented by PPAS for example-- or DB2-like) is quite counter-productive unless we have very good reasons for it... which doesn't mean that we have to do it exactly like they do (specially if we would like to go the incremental implementation route). Amit: mind if I add the DB2 syntax for partitioning to the wiki, too? This might as well help with deciding the final form of partitioning (and define the first implementation boundaries, too) Thanks, / J.L. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers