From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
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-09 16:48:24 |
Message-ID: | 21165.1528562904@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> So it looks like I've assumed that the Append path's partitioned_rels
> will only ever be set for partitioned tables, but it can, in fact, be
> set for UNION ALL parents too when the union children are partitioned
> tables.
> As a discussion topic, I've attached a patch which does resolve the
> error, but it also disables run-time pruning in this case.
> There might be some way we can treat UNION ALL parents differently
> when building the PartitionPruneInfos. I've just not thought of what
> this would be just yet. If I can't think of that, I wonder if this is
> a rare enough case not to bother with run-time partition pruning.
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
?
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2018-06-09 17:05:01 | Re: JIT documentation fixes |
Previous Message | Amit Kapila | 2018-06-09 14:41:04 | Re: hot_standby_feedback vs excludeVacuum and snapshots |