Re: What needs to be done for real Partitioning?
От | Tom Lane |
---|---|
Тема | Re: What needs to be done for real Partitioning? |
Дата | |
Msg-id | 8164.1111341510@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: What needs to be done for real Partitioning? (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: What needs to be done for real Partitioning?
|
Список | 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 по дате отправления: