From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Partitioning WIP patch (was: Partitioning: issues/ideas) |
Date: | 2015-02-26 00:28:52 |
Message-ID: | 54EE68C4.4040900@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/24/15 2:13 AM, Amit Langote wrote:
> -- a plain table
> CREATE TABLE parent_monthly(year int, month int, day int);
>
> -- a partitioned table
> -- xxxxx: number of partitions
> CREATE TABLE parent_monthly_xxxxx(LIKE parent_monthly) PARTITION BY
> RANGE ON(year, month);
To be clear, in this example parent_table_xxxxx is in no way related to
parent_monthly, just like a normal CREATE TABLE (LIKE table), right?
> -- partitions
> CREATE TABLE parent_monthly_xxxxx_201401 PARTITION OF
> parent_monthly_00100_201401 FOR VALUES BETWEEN (2014, 1) AND (2014, 2);
And the partitions are still inheritance children?
Does ALTER TABLE parent_monthly_xxxxx_201401 ADD COLUMN foo still
operate the same as today? I'd like to see us continue to support that,
but perhaps it would be wise to not paint ourselves into that corner
just yet.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2015-02-26 00:32:40 | Re: a fast bloat measurement tool (was Re: Measuring relation free space) |
Previous Message | Tomas Vondra | 2015-02-26 00:15:27 | Re: Performance improvement for joins where outer side is unique |