From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PartitionDispatch's partdesc field |
Date: | 2018-07-26 02:42:31 |
Message-ID: | e33b0a88-07e0-1d3d-f568-6d041dbb2c73@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-07-26 04:49:07 | Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack |
Previous Message | David Rowley | 2018-07-26 02:30:47 | Re: Making "COPY partitioned_table FROM" faster |