Horton

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

David Rowley <david.rowley@2ndquadrant.com>

View thread
From: David Rowley <david.rowley@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Phil Florent <philflorent@hotmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2018-06-09T03:39:25Z
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.

Attachments

On 9 June 2018 at 06:50, David Rowley <david.rowley@2ndquadrant.com> wrote:
> It looks like this was 499be013de6, which was one of mine.
>
> A more simple case to reproduce is:
>
> drop table listp;
> create table listp (a int, b int) partition by list(a);
> create table listp1 partition of listp for values in (1);
> select * from (select * from listp union all select * from listp) t where a = 1;
>
> I'll look in more detail after sleeping.

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.


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