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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Phil Florent <philflorent(at)hotmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian
Date: 2018-06-19 14:28:55
Message-ID: CA+TgmoZRRHkCHTW3+ydZePk-GtnrX7TqtXZPAw4F4Hu26bb6wg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 17, 2018 at 10:59 PM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> Thanks for looking.
>
> Robert, do you have any objections to the proposed patch?

I don't have time to study this right now, but I think the main
possible objection is around performance. If not flattening the
Append is the best way to make queries run fast, then we should do it
that way. If making pruning capable of coping with mixed hierarchies
is going to be faster, then we should do that. If I were to speculate
in the absence of data, my guess would be that failing to flatten the
hierarchy is going to lead to a significant per-tuple cost, while the
cost of making run-time pruning smarter is likely to be incurred once
per rescan (i.e. a lot less). But that might be wrong, and it might
be impractical to get this working perfectly in v11 given the time we
have. But I would suggest that you performance test a query that ends
up feeding lots of tuples through two Append nodes rather than one and
see how much it hurts.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-06-19 14:34:49 Re: row_to_json(), NULL values, and AS
Previous Message Robert Haas 2018-06-19 14:15:33 Re: server crashed with TRAP: FailedAssertion("!(!parallel_aware || pathnode->path.parallel_safe)"