Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian |
| Дата | |
| Msg-id | 31461.1533787220@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
| Ответы |
Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
|
| Список | pgsql-hackers |
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> One reason why we should adapt such a test case is that, in the future, we
> may arrange for make_partitionedrel_pruneinfo(), whose code we just fixed,
> to not be called if we know that run-time pruning is not needed. It seems
> that that's true for the test added by the commit, that is, it doesn't
> need run-time pruning.
Not following your argument here. Isn't make_partition_pruneinfo
precisely what is in charge of figuring out whether run-time pruning
is possible?
(See my point in the other thread about Jaime's assertion crash,
that no run-time pruning actually would be possible for that query.
But we got to the assertion failure anyway.)
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера