Hou-san, On Wed, May 26, 2021 at 10:05 AM houzj.f...@fujitsu.com <houzj.f...@fujitsu.com> wrote: > From: Amit Langote <amitlangot...@gmail.com> > Sent: Tuesday, May 25, 2021 10:06 PM > > Though again, I think we can do this without changing the relcache > > interface, > > such as RelationGetPartitionQual(). > > > > PartitionTupleRouting has all the information that's needed here. > > Each partitioned table involved in routing a tuple to the leaf partition > > has a > > PartitionDispatch struct assigned to it. That struct contains the > > PartitionKey > > and we can access partexprs from there. We can arrange to assemble them > > into a single list that is saved to a given partition's ResultRelInfo, that > > is, after > > converting the expressions to have partition attribute numbers. I tried > > that in > > the attached updated patch; see the 0002-* patch. > > Thanks for the explanation ! > Yeah, we can get all the parent table info from PartitionTupleRouting when > INSERT into a partitioned table. > > But I have two issues about using the information from PartitionTupleRouting > to get the parent table's key expression: > 1) It seems we do not initialize the PartitionTupleRouting when directly > INSERT into a partition(not a partitioned table). > I think it will be better we let the pre-compute-key_expression feature to be > used in all the possible cases, because it > could bring nice performance improvement. > > 2) When INSERT into a partitioned table which is also a partition, the > PartitionTupleRouting is initialized after the ExecPartitionCheck.
Hmm, do we really need to optimize ExecPartitionCheck() when partitions are directly inserted into? As also came up earlier in the thread, we want to discourage users from doing that to begin with, so it doesn't make much sense to spend our effort on that case. Optimizing ExecPartitionCheck(), specifically your idea of pre-computing the partition key expressions, only came up after finding that the earlier patch to teach ExecFindPartition() to cache partitions may benefit from it. IOW, optimizing ExecPartitionCheck() for its own sake does not seem worthwhile, especially not if we'd need to break module boundaries to make that happen. Thoughts? -- Amit Langote EDB: http://www.enterprisedb.com
