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
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 |