Re: What needs to be done for real Partitioning? - Mailing list pgsql-performance

From Tom Lane
Subject Re: What needs to be done for real Partitioning?
Date
Msg-id 8164.1111341510@sss.pgh.pa.us
Whole thread Raw
In response to Re: What needs to be done for real Partitioning?  (Greg Stark <gsstark@mit.edu>)
Responses Re: What needs to be done for real Partitioning?  (Greg Stark <gsstark@mit.edu>)
List pgsql-performance
Greg Stark <gsstark@mit.edu> writes:
> So I think Phase I should look like:

>   An ALTER TABLE command to make an inherited table "abstract" in the object
>   oriented sense. That is, no records can be inserted in the parent table. If
>   you follow the oracle model this is also where you specify the partition
>   key. There's no index associated with this partition key though.

Check.

>   A command to create a new partition, essentially syntactic sugar for a
>   CREATE TABLE with an implied INHERITS clause and a constraint on the
>   partition key. If you follow the oracle model then you explicitly specify
>   which range or specific value of the partition key this partition holds.

Check.

>   A command to remove a partition from the partitioned table and turn it into
>   a regular table.

Ugh.  Why?  You can access the table directly anyway.

>   A command to take a regular table and turn it into a partition.

Double ugh.  Verifying that the table matches the partition scheme seems
like a lot of ugly, bug-prone, unnecessary code.  What's the use case
for this anyway?

Those last two are *certainly* not Phase I requirements, and I don't
think we need them at all ever.

            regards, tom lane

pgsql-performance by date:

Previous
From: PFC
Date:
Subject: Re: What needs to be done for real Partitioning?
Next
From: "Stacy White"
Date:
Subject: Re: What needs to be done for real Partitioning?