Re: Problem with default partition pruning

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: yuzuko <yuzukohosoya(at)gmail(dot)com>, shawn wang <shawn(dot)wang(dot)pg(at)gmail(dot)com>, Shawn Wang <shawn(dot)wang(at)highgo(dot)ca>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Problem with default partition pruning
Date: 2019-08-06 22:17:59
Message-ID: 20190806221759.GA9127@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-Aug-06, Alvaro Herrera wrote:

> Well, if this is really all that duplicative, one thing we could do is
> run this check in get_partprune_steps_internal only if
> constraint_exclusion is a value other than on; we should achieve the
> same effect with no repetition. Patch for that is attached. However,
> if I run the server with constraint_exclusion=on, the regression test
> fail with the attached diff. I didn't look at what test is failing, but
> it seems to me that it's not really duplicative in all cases, only some.
> Therefore we can't do it.

Right ... One of the failing cases is one that was benefitting from
constraint_exclusion in the location where we were doing it previously.

I think trying to fix this problem by selectively moving where to apply
constraint exclusion would be very bug-prone, and hard to detect whether
we're missing one spot or doing it multiple times in some other cases.
So I think we shouldn't try. If this is a real problem, then we should
add a flag to the reloptinfo and set it when we've done pruning, then
do nothing if we already did it. I'm not sure that this is correct, and
I'm even less sure that it is worth the trouble.

In short, I propose to get this done as the patch I posted in
https://postgr.es/m/20190806133053.GA23706@alvherre.pgsql

Cheers

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-08-06 22:27:35 no default hash partition
Previous Message Jonathan S. Katz 2019-08-06 22:13:30 Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)