Re: Problem with default partition pruning

Hi Alvaro,

On Tue, Aug 13, 2019 at 2:45 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> 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