Re: [HACKERS] Declarative partitioning - another take
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] Declarative partitioning - another take |
Дата | |
Msg-id | cdc57989-8869-ee8c-3c38-1dd9b4a92349@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Declarative partitioning - another take (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On 2016/12/16 17:02, Amit Langote wrote: > [PATCH 2/7] Change how RelationGetPartitionQual() and related code works > > Since we always want to recurse, ie, include the parent's partition > constraint (if any), get rid of the argument recurse. > > Refactor out the code doing the mapping of attnos of Vars in partition > constraint expressions (parent attnos -> child attnos). Move it to a > separate function map_partition_varattnos() and call it from appropriate > places. It previously used to be done in get_qual_from_partbound(), > which would lead to wrong results in certain multi-level partitioning > cases, as the mapping would be done for immediate parent-partition pairs. > Now in generate_partition_qual() which is the workhorse of > RelationGetPartitionQual(), we first generate the full expression > (considering all levels of partitioning) and then do the mapping from the > root parent to a leaf partition. It is also possible to generate > partition constraint up to certain non-leaf level and then apply the > same to leaf partitions of that sub-tree after suitable substitution > of varattnos using the new map_partition_varattnos() directly. > > Bug fix: ATExecAttachPartition() failed to do the mapping when attaching > a partitioned table as partition. It is possible for the partitions of > such table to have different attributes from the table being attached > and/or the target partitioned table. Oops, PATCH 2/7 attached with the previous email had a bug in it, whereby map_partition_varattnos() was not applied to the partition constraint expressions returned directly from the relcache (rd_partcheck) copy. Attaching just the updated (only) PATCH 2 which fixes that. Patches 1,3,4,5,6,7/7 from the previous email [1] are fine. Sorry about that. Thanks, Amit [1] https://www.postgresql.org/message-id/c820c0eb-6935-6f84-8c6a-785fdff130c1@lab.ntt.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: