Re: PartitionDispatch's partdesc field
Amit Langote <langote_amit_f8@lab.ntt.co.jp>
From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Robert Haas <robertmhaas@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-07-26T02:42:31Z
Lists: pgsql-hackers
On 2018/07/26 5:23, Robert Haas wrote: > I noticed today that in the PartitionDispatch structure, the partdesc > field is set but not used. So we could remove it. See attached > pd-partdesc-remove.patch. If we want to go this route, I suggest > doing a slightly more thorough removal and getting rid of the key > field as well. See attached pd-partdesc-and-key-remove.patch. > > Another alternative, which I think might make more sense, is to make > use pd->key and pd->partdesc in preference to pd->reldesc->rd_partkey > and pd->reldesc->rd_partdesc. It seems to me that the idea of the > PartitionDispatch structure is that it gathers together all of the > information that we need for tuple routing, so it might make sense for > the tuple routing code ought to get the information from there rather > than referring back to the RelationDesc. See attached > pd-partdesc-use.patch. +1 to pd-partdesc-use.patch. > Basically, the decision here is whether we want to avoid invoking > RelationGetPartitionKey and RelationGetPartitionDesc over and over > again, either for reasons of notational cleanliness (macro names are > long) or safety (absolutely no chance that the answer will change) or > efficiency (maybe those macros will someday do more than just a > pointer dereference?). If so, we should cache the data in the > PartitionDispatch object and then use it. I agree. Thanks, Amit
Commits
-
Use key and partdesc from PartitionDispatch where possible.
- 3e3210904914 12.0 landed