Re: Problem with default partition pruning

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: hosoya(dot)yuzuko(at)lab(dot)ntt(dot)co(dot)jp
Cc: Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp, thibaut(dot)madelaine(at)dalibo(dot)com, imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Problem with default partition pruning
Date: 2019-04-09 01:28:48
Message-ID: 20190409.102848.252476604.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Mon, 8 Apr 2019 16:57:35 +0900, "Yuzuko Hosoya" <hosoya(dot)yuzuko(at)lab(dot)ntt(dot)co(dot)jp> wrote in <00c101d4ede0$babd4390$3037cab0$(at)lab(dot)ntt(dot)co(dot)jp>
> > BTW, now I'm a bit puzzled between whether this case should be fixed by hacking on partprune.c like
> > this patch does or whether to work on getting the other patch committed and expect users to set
> > constraint_exclusion = on for this to behave as expected. The original intention of setting
> > partition_qual in set_relation_partition_info() was for partprune.c to use it to remove useless
> > arguments of OR clauses which otherwise would cause the failure to correctly prune the default partitions
> > of sub-partitioned tables. As shown by the examples in this thread, the original effort was
> > insufficient, which this patch aims to improve. But, it also expands the scope of partprune.c's usage
> > of partition_qual, which is to effectively perform full-blown constraint exclusion without being
> > controllable by constraint_exclusion GUC, which may be seen as being good or bad. The fact that it
> > helps in getting partition pruning working correctly in more obscure cases like those discussed in
> > this thread means it's good maybe.
> >
> Umm, even though this modification might be overhead, I think this problem should be solved
> without setting constraint_exclusion GUC. But I'm not sure.

As the second thought. Partition constraint is not constraint
expression so that's fair to apply partqual ignoring
constraint_exclusion. The variable is set false to skip useless
expression evaluation on all partitions, but partqual should be
evaluated just once. Sorry for my confusion.

So still it is wrong that the new code is added in
gen_partprune_steps_internal. If partqual results true and the
clause is long, the partqual is evaluated uselessly at every
recursion.

Maybe we should do that when we find that the current clause
doesn't match part attributes. Specifically just after the for
loop "for (i = 0 ; i < part_scheme->partnattrs; i++)".

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2019-04-09 01:33:17 Re: Problem with default partition pruning
Previous Message Andres Freund 2019-04-09 01:04:40 Re: Zedstore - compressed in-core columnar storage