Re: FailedAssertion on partprune - Mailing list pgsql-hackers

From David Rowley
Subject Re: FailedAssertion on partprune
Date
Msg-id CAKJS1f_mHTXNnAKKCqckwTNemYPE3LjefsU6yYcpxU6wfjmg_A@mail.gmail.com
Whole thread Raw
In response to Re: FailedAssertion on partprune  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: FailedAssertion on partprune  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On 25 July 2018 at 01:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hm, wouldn't this be fixed by your pending patch at
> <CAKJS1f_eYwHk2x0xX7qW42rV_GRsJGBMe3AqN9MYLRSs1S+CiA@mail.gmail.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Have an encrypted pgpass file
Next
From: Tomas Vondra
Date:
Subject: Re: GSOC 2018 Project - A New Sorting Routine