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

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

Well, I hadn't bothered to put in the extra code needed to have a qual
to prune with, but my point remains that it doesn't seem like the current
Append code is prepared to cope with an Append that contains partitions
of more than one top-level partitioned table.

I just had a thought that might lead to a nice solution to that, or
might be totally crazy.  What if we inverted the sense of the bitmaps
that track partition pruning state, so that instead of a bitmap of
valid partitions that need to be scanned, we had a bitmap of pruned
partitions that we know we don't need to scan?  (The indexes of this
bitmap would be subplan indexes not partition indexes.)  With this
representation, it doesn't matter if some of the Append's children
are not supposed to participate in pruning; they just don't ever get
added to the bitmap of what to skip.  It's also fairly clear, I think,
how to handle independent pruning rules for different top-level tables
that are being unioned together: just OR the what-to-skip bitmaps.
But there may be some reason why this isn't workable.

			regards, tom lane