Re: Auto creation of Partitions
От | NikhilS |
---|---|
Тема | Re: Auto creation of Partitions |
Дата | |
Msg-id | d3c4af540703080022l1cd34e7fo5e6712391bec0839@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Auto creation of Partitions (Jim Nasby <decibel@decibel.org>) |
Ответы |
Re: Auto creation of Partitions
|
Список | pgsql-hackers |
Hi,
The consensus seems to be veering towards triggers.
Since partition is inheritance-based, a simple DROP or "NO INHERIT" will do the job to deal with the partition. Do we want to reinvent additional syntax when these are around and are documented?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
There are 2 other reasons to favor triggers though:
1) People (Josh Drake comes to mind) have found that if you get over
a tiny number of partitions, the performance of rules is abysmal.
2) I believe it should be possible to construct an update trigger
that allows you to perform updates that will place the row in
question into a new partition. While I can see cases for simply
disallowing updates to the partitioning key, I think there are also
times when being able to do that would be very useful.
The consensus seems to be veering towards triggers.
I think it'd be great to make adding and removing partitions as
simple as ALTER TABLE. I don't think that DELETE should be the
mechanism to drop a partition, though. Again, DML statements
shouldn't be performing DDL.
Since partition is inheritance-based, a simple DROP or "NO INHERIT" will do the job to deal with the partition. Do we want to reinvent additional syntax when these are around and are documented?
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: