Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Internal error XX000 with enable_partition_pruning=on, pg 11beta1 on Debian
Дата
Msg-id CAKJS1f87rowp-zZW-oOvRYQsehi-g9ZSMuJwYGqy9rdAskFSkw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 10 June 2018 at 04:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So, IIUC, the issue is that for partitioning cases Append expects *all*
> its children to be partitions of the *same* partitioned table?  That
> is, you could also break it with
>
>         select * from partitioned_table_a
>         union all
>         select * from partitioned_table_b
>
> ?

Not quite. I think what I sent above is the most simple way to break
it. Your case won't because there are no quals to prune with, so
run-time pruning is never attempted.

> If so, maybe the best solution is to not allow a partitioning appendrel
> to be flattened into an appendrel generated in other ways (particularly,
> via UNION ALL).  I also wonder whether it was a bad idea to treat these
> as the same kind of path/plan in the first place.

That might be the best idea. I'll look into that now. The only
drawback I see is that we'll end up pulling tuples through more Append
nodes in cases like you mentioned above.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: why partition pruning doesn't work?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pg_replication_slot_advance to return NULL instead of 0/0 ifslot not advanced