RE: Skip partition tuple routing with constant partition key

Поиск
Список
Период
Сортировка
От houzj.fnst@fujitsu.com
Тема RE: Skip partition tuple routing with constant partition key
Дата
Msg-id OS0PR01MB57160B80213127D5F9862276943E9@OS0PR01MB5716.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Skip partition tuple routing with constant partition key  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: Skip partition tuple routing with constant partition key  (Amit Langote <amitlangote09@gmail.com>)
Список pgsql-hackers
Hi Amit-san

From: Amit Langote <amitlangote09@gmail.com>
Sent: Thursday, May 27, 2021 4:46 PM
> Hou-san,
> 
> On Thu, May 27, 2021 at 3:56 PM houzj.fnst@fujitsu.com
> <houzj.fnst@fujitsu.com> wrote:
> > From: Amit Langote <amitlangote09@gmail.com>
> > Sent: Thursday, May 27, 2021 1:54 PM
> > > On Thu, May 27, 2021 at 11:47 AM houzj.fnst@fujitsu.com
> > > <houzj.fnst@fujitsu.com> wrote:
> > > > About teaching relcache about caching the target partition.
> > > >
> > > > David-san suggested cache the partidx in PartitionDesc.
> > > > And it will need looping and checking the cached value at each level.
> > > > I was thinking can we cache a partidx list[1, 2 ,3], and then we
> > > > can follow the list to get the last partition and do the partition
> > > > CHECK only for the last partition. If any unexpected thing happen,
> > > > we can return to the original table and redo the tuple routing
> > > > without using the
> > > cached index.
> > > > What do you think ?
> > >
> > > 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:
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.

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.

Best regards,
houzj

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: A new function to wait for the backend exit after termination
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: security_definer_search_path GUC