Re: Skip partition tuple routing with constant partition key

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Skip partition tuple routing with constant partition key
Дата
Msg-id CA+HiwqE8pNeXqC4FMkOMgbK52m0PmS=0aLxfAFsT7a_4EiFp8g@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Skip partition tuple routing with constant partition key  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Ответы RE: Skip partition tuple routing with constant partition key  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Список pgsql-hackers
Hou-san,

On Wed, May 26, 2021 at 10:05 AM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
> From: Amit Langote <amitlangote09@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



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Incorrect GUC descriptions in docs and postgresql.conf.sample
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: storing an explicit nonce