Re: Problem with default partition pruning

Hi Alvaro,

On Tue, Aug 13, 2019 at 2:45 AM Alvaro Herrera  wrote:
> v3-0001 still seems to leave things a bit duplicative.  I think we can
> make it better if we move the logic to set RelOptInfo->partition_qual to
> a separate routine (set_baserel_partition_constraint mirroring the
> existing set_baserel_partition_key_exprs), and then call that from both
> places that need access to partition_qual.
>
> So I propose that the attached v4 patch should be the final form of this
> (also rebased across today's list_concat API change).  I verified that
> constraint exclusion is not being called by partprune unless a default
> partition exists (thanks errbacktrace()); I think that should appease
> Simon's performance concern for the most common case of default
> partition not existing.
>
> I think I was not really understanding the comments being added by
> Amit's v3, so I reworded them.  I hope I understood the intent of the
> code correctly.

Thanks a lot for revising.  Looks neat, except:

+     * This is a measure of last resort only to be used because the default
+     * partition cannot be pruned using the steps; regular pruning, which is
+     * cheaper, is sufficient when no default partition exists.

This text appears to imply that the default can *never* be pruned with
steps.  Maybe, the first sentence should read something like: "...the
default cannot be pruned using the steps generated from clauses that
contradict the parent's partition constraint".

> I'm not comfortable with RelOptInfo->partition_qual.  But I'd rather
> leave that for another time.

Sure.

Regards,
Amit