RE: Problem with default partition pruning

Horiguchi-san,

Thanks for your comments.

> -----Original Message-----
> From: Kyotaro HORIGUCHI [mailto:horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp]
> Sent: Tuesday, April 09, 2019 10:33 AM
> 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
>
> Sigh..
>
> At Tue, 09 Apr 2019 10:28:48 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in
> <20190409(dot)102848(dot)252476604(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
> > 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.
>
> So still it is wrong that the new code is added at the beginning of the loop on clauses 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++)".
>
I think we should check whether WHERE clause contradicts partition
constraint even when the clause matches part attributes. So I moved
"if (partqual)" block to the beginning of the loop you mentioned.

I'm attaching the latest version. Could you please check it again?

Best regards,
Yuzuko Hosoya