> >> Yes, it's hard, but I think without having a separate RelOptInfo the >> design won't be complete. Is there a subset of problem that can be >> solved by using a separate RelOptInfo e.g. pushing aggregates down >> child relations or anything else. > > I'm still not convinced that all the fields of RelOptInfo (typically relids) > need to be duplicated. If the current concept should be improved, I'd move all > the grouping related fields to a separate structure, e.g. GroupPathInfo, and > let RelOptInfo point to it. Similar to ParamPathInfo, which contains > parameterization-specific information, GroupPathInfo would conain the > grouping-specific information: target, row count, width, maybe path lists too. >
I didn't think about this option. Still not very clean, but may be acceptable. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
