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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] advanced partition matching algorithm for partition-wise join
Дата
Msg-id 2750.1586410602@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] advanced partition matching algorithm forpartition-wise join  (Etsuro Fujita <etsuro.fujita@gmail.com>)
Ответы Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
Список pgsql-hackers
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.  The assertion cost would be cheap, but not zero, so I still
> think it would be better to remove the assertion from
> partition_bounds_merge().

FWIW, our general policy is that assertion costs should be ignored
in any performance considerations.  If you're concerned about
performance you should be running a non-assert build, so it doesn't
matter.  (And certainly, there are lots of assertions in the backend
that cost FAR more than this one.)  The thing to evaluate an assertion
on is how likely it is that it would catch a foreseeable sort of coding
error in some future patch.  Maybe this one carries its weight on that
score or maybe it doesn't, but that's how to think about it.

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.

            regards, tom lane



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Vacuum o/p with (full 1, parallel 0) option throwing an error
Следующее
От: Thomas Munro
Дата:
Сообщение: Fast DSM segments