From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Phil Florent <philflorent(at)hotmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian |
Date: | 2018-06-10 13:16:23 |
Message-ID: | CAKJS1f87rowp-zZW-oOvRYQsehi-g9ZSMuJwYGqy9rdAskFSkw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10 June 2018 at 04:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-06-10 13:19:23 | Re: pg_replication_slot_advance to return NULL instead of 0/0 if slot not advanced |
Previous Message | David Rowley | 2018-06-10 13:11:33 | Re: why partition pruning doesn't work? |