Re: Partitioning WIP patch (was: Partitioning: issues/ideas) - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Partitioning WIP patch (was: Partitioning: issues/ideas)
Date
Msg-id 54EE68C4.4040900@BlueTreble.com
Whole thread Raw
In response to Partitioning WIP patch (was: Partitioning: issues/ideas)  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: Partitioning WIP patch  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List 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



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Performance improvement for joins where outer side is unique
Next
From: Simon Riggs
Date:
Subject: Re: a fast bloat measurement tool (was Re: Measuring relation free space)