Re: Auto creation of Partitions
От | NikhilS |
---|---|
Тема | Re: Auto creation of Partitions |
Дата | |
Msg-id | d3c4af540703070352k4bd631deyd328050f60678430@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Auto creation of Partitions ("Simon Riggs" <simon@2ndquadrant.com>) |
Список | pgsql-hackers |
Hi,
If the unique constraint is supposed to be on a column which is NOT being used for the partitioning, then all the above becomes much more difficult.
While partitioning, the additional onus on the user is to specify non-conflicting CHECKs for the range/list partitions.
Regards,
Nikhils
--
EnterpriseDB http://www.enterprisedb.com
If you know that the constraints on each of the tables is distinct, then
building a UNIQUE index on each of the partitions is sufficient to prove
that all rows in the combined partitioned table are distinct also.
The hard part there is checking that the partition constraints are
distinct. If the partition constraints are added one at a time, you can
use the predicate testing logic to compare the to-be-added partition's
constraint against each of the already added constraints. That becomes
an O(N) problem.
What is really needed is a data structure that allows range partitions
to be accessed more efficiently. This could make adding partitions and
deciding in which partition a specific value goes an O(logN) operation.
If the unique constraint is supposed to be on a column which is NOT being used for the partitioning, then all the above becomes much more difficult.
While partitioning, the additional onus on the user is to specify non-conflicting CHECKs for the range/list partitions.
Regards,
Nikhils
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
--
EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: