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

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
Дата
Msg-id CAPmGK15AAW2Y7f=p+uBP2tj8H079iw4p0N=W4rwz3e0gqgEdKQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] advanced partition matching algorithm for partition-wise join  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
Список pgsql-hackers
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.

Best regards,
Etsuro Fujita



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Vacuum o/p with (full 1, parallel 0) option throwing an error