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