Re: [HACKERS] moving some partitioning code to executor
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] moving some partitioning code to executor |
Дата | |
Msg-id | 065e9b24-c9af-1e58-2643-028786393824@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | [HACKERS] moving some partitioning code to executor (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] moving some partitioning code to executor
|
Список | pgsql-hackers |
On 2017/09/14 16:13, Amit Langote wrote: > Hi. > > It seems to me that some of the code in partition.c is better placed > somewhere under the executor directory. There was even a suggestion > recently [1] to introduce a execPartition.c to house some code around > tuple-routing. > > IMO, catalog/partition.c should present an interface for handling > operations on a *single* partitioned table and avoid pretending to support > any operations on the whole partition tree. For example, the > PartitionDispatch structure embeds some knowledge about the partition tree > it's part of, which is useful when used for tuple-routing, because of the > way it works now (lock and form ResultRelInfos of *all* leaf partitions > before the first input row is processed). > > So, let's move that structure, along with the code that creates and > manipulates the same, out of partition.c/h and to execPartition.c/h. > Attached patch attempts to do that. > > While doing the same, I didn't move *all* of get_partition_for_tuple() out > to execPartition.c, instead modified its signature as shown below: > > -extern int get_partition_for_tuple(PartitionDispatch *pd, > - TupleTableSlot *slot, > - EState *estate, > - PartitionDispatchData **failed_at, > - TupleTableSlot **failed_slot); > +extern int get_partition_for_tuple(Relation relation, Datum *values, > + bool *isnull); > > That way, we keep the core partition bound comparison logic inside > partition.c and move rest of the stuff to its caller ExecFindPartition(), > which includes navigating the enveloping PartitionDispatch's. > > Thoughts? > > PS: 0001 of the attached is the patch from [2] which is here to be applied > on HEAD before applying the main patch (0002) itself Since that 0001 patch was committed [1], here is the rebased patch. Will add this to the November commit-fest. Thanks, Amit [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=77b6b5e9c -- 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 по дате отправления: