Re: ON CONFLICT DO UPDATE for partitioned tables
От | Pavan Deolasee |
---|---|
Тема | Re: ON CONFLICT DO UPDATE for partitioned tables |
Дата | |
Msg-id | CABOikdOOBv75hCRFf3aYMB_YEGj0GVptxy8S3D7W9nnEfrC2ZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ON CONFLICT DO UPDATE for partitioned tables (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: ON CONFLICT DO UPDATE for partitioned tables
|
Список | pgsql-hackers |
On Fri, Mar 16, 2018 at 5:13 PM, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:
(2018/03/16 19:43), Pavan Deolasee wrote:On Fri, Mar 2, 2018 at 9:06 PM, Alvaro Herrera <alvherre@2ndquadrant.com
<mailto:alvherre@2ndquadrant.com>> wrote: @@ -106,6 +120,9 @@ typedef struct PartitionTupleRouting
int num_subplan_partition_offsets;
TupleTableSlot *partition_tuple_slot;
TupleTableSlot *root_tuple_slot;
+ List **partition_arbiter_indexes;
+ TupleTableSlot **partition_conflproj_slots;
+ TupleTableSlot **partition_existing_slots;
} PartitionTupleRouting;I am curious why you decided to add these members to
PartitionTupleRouting structure. Wouldn't ResultRelationInfo be a better
place to track these or is there some rule that we follow?
I just started reviewing the patch, so maybe I'm missing something, but I think it would be a good idea to have these in that structure, not in ResultRelInfo, because these would be required only for partitions chosen via tuple routing.
Hmm, yeah, probably you're right. The reason I got confused is because the patch uses ri_onConflictSetProj/ri_onConflictSetWhere to store the converted projection info/where clause for a given partition in its ResultRelationInfo. So I was wondering if we can move mt_arbiterindexes, mt_existing and mt_conflproj to ResultRelInfo and then just use that per-partition structures too.
Thanks,
Pavan
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: