Re: Skip partition tuple routing with constant partition key

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Skip partition tuple routing with constant partition key
Date: 2021-05-20 00:37:03
Message-ID: CAApHDvrxhsW59ugAfTLTSS3uwhh+ZXNOJaGOq+E4Vsk4kQ_1KQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 20 May 2021 at 12:20, tsunakawa(dot)takay(at)fujitsu(dot)com
<tsunakawa(dot)takay(at)fujitsu(dot)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 is trying 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-05-20 00:39:13 Re: Commitfest app vs. pgsql-docs
Previous Message Amit Langote 2021-05-20 00:32:25 Re: Subscription tests fail under CLOBBER_CACHE_ALWAYS