Re: Skip partition tuple routing with constant partition key

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Skip partition tuple routing with constant partition key
Дата
Msg-id CAApHDvrxhsW59ugAfTLTSS3uwhh+ZXNOJaGOq+E4Vsk4kQ_1KQ@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Skip partition tuple routing with constant partition key  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Список pgsql-hackers
On Thu, 20 May 2021 at 12:20, tsunakawa.takay@fujitsu.com
<tsunakawa.takay@fujitsu.com> wrote:
> Yes, I want to make/keep it possible that application developers can be unaware of partitions.  I believe that's why
David-san,Alvaro-san, and you have made great efforts to improve partitioning performance.  So, I'm +1 for what Hou-san
istrying to achieve. 
>
> Is there something you're concerned about?  The amount and/or complexity of added code?

It would be good to see how close Amit's patch gets to the performance
of the original patch on this thread.  As far as I can see, the
difference is, aside from the setup code to determine if the partition
is constant, that Amit's patch just requires an additional
ExecPartitionCheck() call per row.  That should be pretty cheap when
compared to the binary search to find the partition for a RANGE or
LIST partitioned table.

Houzj didn't mention how the table in the test was partitioned, so
it's hard to speculate how many comparisons would be done during a
binary search. Or maybe it was HASH partitioned and there was no
binary search.

David



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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Commitfest app vs. pgsql-docs