Re: Skip partition tuple routing with constant partition key - Mailing list pgsql-hackers

From David Rowley
Subject Re: Skip partition tuple routing with constant partition key
Date
Msg-id CAApHDvrxhsW59ugAfTLTSS3uwhh+ZXNOJaGOq+E4Vsk4kQ_1KQ@mail.gmail.com
Whole thread Raw
In response to RE: Skip partition tuple routing with constant partition key  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
List 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 by date:

Previous
From: Amit Langote
Date:
Subject: Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS
Next
From: Michael Paquier
Date:
Subject: Re: Commitfest app vs. pgsql-docs