On Wed, Jul 1, 2020 at 6:56 PM Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 2 Mar 2020, at 06:08, Amit Langote <amitlangote09@gmail.com> wrote:
> >
> > On Mon, Mar 2, 2020 at 4:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Amit Langote <amitlangote09@gmail.com> writes:
> >>> Rebased again.
> >>
> >> Seems to need that again, according to cfbot :-(
> >
> > Thank you, done.
>
> ..and another one is needed as it no longer applies, please submit a rebased
> version.
Sorry, it took me a while to get to this.
It's been over 11 months since there was any significant commentary on
the contents of the patches themselves, so perhaps I should reiterate
what the patches are about and why it might still be a good idea to
consider them.
The thread started with some very valid criticism of the way
executor's partition tuple routing logic looks randomly sprinkled over
in nodeModifyTable.c, execPartition.c. In the process of making it
look less random, we decided to get rid of the global variable
es_result_relation_info to avoid complex maneuvers of
setting/resetting it correctly when performing partition tuple
routing, causing some other churn beside the partitioning code. Same
with another global variable TransitionCaptureState.tcs_map. So, the
patches neither add any new capabilities, nor improve performance, but
they do make the code in this area a bit easier to follow.
Actually, there is a problem that some of the changes here conflict
with patches being discussed on other threads ([1], [2]), so much so
that I decided to absorb some changes here into another "refactoring"
patch that I have posted at [2].
Attached rebased patches.
0001 contains preparatory FDW API changes to stop relying on
es_result_relation_info being set correctly.
0002 removes es_result_relation_info in favor passing the active
result relation around as a parameter in the various functions that
need it
0003 Moves UPDATE tuple-routing logic into a new function
0004 removes the global variable TransitionCaptureState.tcs_map which
needed to be set/reset whenever the active result relation relation
changes in favor of a new field in ResultRelInfo to store the same map
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
[1] https://commitfest.postgresql.org/28/2575/
[2] https://commitfest.postgresql.org/28/2621/
