Re: FailedAssertion on partprune

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jaime Casanova <jaime(dot)casanova(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FailedAssertion on partprune
Date: 2018-08-01 14:35:09
Message-ID: CAKJS1f9e7hHYP9SaT=-_RR4jdmm9VCgtDoC3-60s97EMjcfGWg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 31 July 2018 at 11:25, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Not looking at the code right now either, but removing that assert and
> then removing the TABLESAMPLE clause, the query returns identical
> results with and without pruning, so maybe you're right. No time for
> further looking now.

I thought about this a bit more and it seems fine just to remove the
Assert. The patch that's pending in [1] adds all the correct handling
for subplans that don't belong in any partition hierarchy. That's not
the case for Jaime's plan, but those sub-partitioned tables will be
identified just like any other partition by the run-time pruning code
and can be pruned in the same way.

The attached patch removes the Assert, but I think it should be
probably be done as part of [1]'s patch since that's also adding the
code to handle subplans for tables that don't belong in the partition
hierarchy.

I also spent a bit of time trying to create a simple test case for
this and I've discovered that it's really not very easy and I have
doubts about how stable such a plan might be.

> (SELECT 'Jaime' <> 'Jamie' COLLATE es_EC)

Apologies. It was a finger auto-pilot malfunction.

[1] https://www.postgresql.org/message-id/CAKJS1f_eYwHk2x0xX7qW42rV_GRsJGBMe3AqN9MYLRSs1S%2BCiA%40mail.gmail.com

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

Attachment Content-Type Size
remove_incorrect_partprune_assert.patch application/octet-stream 549 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-08-01 14:42:18 Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian
Previous Message Tom Lane 2018-08-01 14:27:34 Re: Explain buffers wrong counter with parallel plans