Hi Alvaro, On Tue, Aug 13, 2019 at 2:45 AM Alvaro Herrera <alvhe...@2ndquadrant.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