Re: Skip partition tuple routing with constant partition key
Amit Langote <amitlangote09@gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
To: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Cc: David Rowley <dgrowleyml@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>
Date: 2021-06-03T11:48:57Z
Lists: pgsql-hackers
Hou-san, On Tue, Jun 1, 2021 at 5:43 PM houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com> wrote: > From: Amit Langote <amitlangote09@gmail.com> > > > > Where are you thinking to cache the partidx list? Inside > > > > PartitionDesc or some executor struct? > > > > > > I was thinking cache the partidx list in PartitionDescData which is in > > > relcache, if possible, we can use the cached partition between statements. > > > > Ah, okay. I thought you were talking about a different idea. > > How and where would you determine that a cached partidx value is indeed the correct one for > > a given row? > > Anyway, do you want to try writing a patch to see how it might work? > > Yeah, the different idea here is to see if it is possible to share the cached > partition info between statements efficiently. > > But, after some research, I found something not as expected: Thanks for investigating this. > Currently, we tried to use ExecPartitionCheck to check the if the cached > partition is the correct one. And if we want to share the cached partition > between statements, we need to Invoke ExecPartitionCheck for single-row INSERT, > but the first time ExecPartitionCheck call will need to build expression state > tree for the partition. From some simple performance tests, the cost to build > the state tree could be more than the cached partition saved which could bring > performance degradation. Yeah, using the executor in the lower layer will defeat the whole point of caching in that layer. > So, If we want to share the cached partition between statements, we seems cannot > use ExecPartitionCheck. Instead, I tried directly invoke the partition support > function(partsupfunc) to check If the cached info is correct. In this approach I > tried cache the *bound offset* in PartitionDescData, and we can use the bound offset > to get the bound datum from PartitionBoundInfoData and invoke the partsupfunc > to do the CHECK. > > Attach a POC patch about it. Just to share an idea about sharing cached partition info > between statements. I have not looked at your patch yet, but yeah that's what I would imagine doing it. -- Amit Langote EDB: http://www.enterprisedb.com
Commits
-
Have ExecFindPartition cache the last found partition
- 3592e0ff98b1 16.0 landed
-
Fix publish_as_relid with multiple publications
- c91f71b9dc91 15.0 cited