On Mon, Dec 11, 2017 at 3:16 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > > Sometime in the future, I'd like to see some sort of UniqueKeys List > in RelOptInfo which is initially populated by using looking at the > unique indexes during build_simple_rel(). The idea is that these > UniqueKeys would get propagated into RELOPT_JOINRELs when the join > condition matches a set of unique keys on the other side of the join. > e.g. If the outer side of the join had a UniqueKey matching the join > condition then we could take all of the UniqueKeys from the RelOptInfo > for the inner side of the join (and vice versa). This infrastructure > would allow us to no-op a DISTINCT when the RelOptInfo has targetlist > items which completely cover at least one UniqueKey set, or not bother > performing a sort for a GROUP BY when the GROUP BY clause is covered > by a UniqueKey. >
That looks neat. > To fix the case we're discussing, we can also propagate those > UniqueKeys to an AppendPath with a single subpath similar to how I'm > propagating the PathKeys for the same case in this patch, that way the > unique join code would find the UniqueKeys instead of what it does > today and not find any unique indexes on the partitioned table. > Another possibility is to support partition-wise join between an unpartitioned table and a partitioned table by joining the unpartitioned table with each partition separately and appending the results. That's a lot of work and quite some new infrastructure. Each of those join will pick unique key if appropriate index exists on the partitions. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
