Re: Partitioning WIP patch (was: Partitioning: issues/ideas)

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

In response to

Responses

Browse pgsql-hackers by date

  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