Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On Thu, Apr 09, 2020 at 07:34:01PM +0530, Ashutosh Bapat wrote:
>On Thu, Apr 9, 2020 at 12:03 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
>>
>> On Thu, Apr 9, 2020 at 2:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> writes:
>> > > Yeah, partition_bounds_merge() is currently called only from
>> > > try_partitionwise_join(), which guarantees that the strategies are the
>> > > same.
>>
>> > If there's only one caller and there's not likely to ever be more,
>> > then I tend to agree that you don't need the assertion.
>>
>> It seems unlikely that partition_bounds_merge() will be called from
>> more places in the foreseeable future, so I'd still vote for removing
>> the assertion.
>
>When I wrote that function, I had UNION also in mind. A UNION across
>multiple partitioned relations will be partitioned if we can merge the
>partition bounds in a sensible manner. Of course the current structure
>of that function looks more purposed for join, but it's not difficult
>to convert it to be used for UNION as well. In that case those set of
>functions will have many more callers. So, I will vote to keep that
>assertion now that we have it there.

Yeah. I really don't see why we should remove an assertion that enforces
something useful, especially when it's just a plain comparions. Had it
been some expensive assert, maybe. But how much slower does this make
an assert-enabled build? 0.000000000001% or something like that?

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services