Re: FailedAssertion on partprune

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FailedAssertion on partprune
Date: 2018-07-24 14:14:34
Message-ID: CAKJS1f_mHTXNnAKKCqckwTNemYPE3LjefsU6yYcpxU6wfjmg_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25 July 2018 at 01:46, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Hm, wouldn't this be fixed by your pending patch at
> <CAKJS1f_eYwHk2x0xX7qW42rV_GRsJGBMe3AqN9MYLRSs1S+CiA(at)mail(dot)gmail(dot)com>
> ?

It's a different issue. I coded run-time pruning with the incorrect
assumption that we only get leaf partitions under an Append which have
a non-empty partitioned_rels List. The other patch fixes it to
supported mixed hierarchies from UNION ALLs. It'll still trip up on
anything apart from leaf partitions being in the subpaths list.

Thinking again about the patch I submitted upthread; I wonder if it's
actually possible to support pruning with Jamie's query. Without
looking at the code, I don't quite see the reason that the
sub-partitioned table wouldn't be correctly pruned by the run-time
pruning code. It could just be a matter of removing the failing
Assert(). I'll do a bit more testing and confirm.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-07-24 15:16:03 Re: GSOC 2018 Project - A New Sorting Routine
Previous Message Tom Lane 2018-07-24 14:00:21 Re: Have an encrypted pgpass file