Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Phil Florent <philflorent@hotmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-06-09T16:48:24Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Match RelOptInfos by relids not pointer equality.

  2. Fix run-time partition pruning for appends with multiple source rels.

David Rowley <david.rowley@2ndquadrant.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