Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
От | Tomas Vondra |
---|---|
Тема | Re: [HACKERS] advanced partition matching algorithm forpartition-wise join |
Дата | |
Msg-id | 20200409144100.a5o6lg47a6aexe5n@development обсуждение исходный текст |
Ответ на | Re: [HACKERS] advanced partition matching algorithm forpartition-wise join (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Список | pgsql-hackers |
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.fujita@gmail.com> wrote: >> >> On Thu, Apr 9, 2020 at 2:36 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > Etsuro Fujita <etsuro.fujita@gmail.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
В списке pgsql-hackers по дате отправления: