At Thu, 6 Apr 2017 13:10:48 +1200, David Rowley <david.row...@2ndquadrant.com> wrote in <CAKJS1f8Um=bvrmgcb3u6ze1q1xl7a1vktvf9s2r1_ufrqx8...@mail.gmail.com> > On 6 April 2017 at 13:05, David Rowley <david.row...@2ndquadrant.com> wrote: > > I tested with the attached, and it does not seem to hurt planner > > performance executing: > > Here's it again, this time with a comment on the > find_relation_from_clauses() function.
It seems to work as the same as the previous version with additional cost to scan over restrict clauses. But separate loop over clauses is additional overhead in any cases even irrelavant to functional dependency. The more columns are in the relation, the longer time bms_get_singleton_member takes. Although I'm not sure how much it hurts performance and I can't think of a good alternative right now, I think that the overhead should be avoided anyhow. At Thu, 6 Apr 2017 13:05:24 +1200, David Rowley <david.row...@2ndquadrant.com> wrote in <CAKJS1f_gB=gyZn8wMw0v8uCKD1nYeWyNYCXKz=+oo0yr4rr...@mail.gmail.com> > > And you measured the overhead of doing it the other way to be ... ? > > Premature optimization and all that. > > I tested with the attached, and it does not seem to hurt planner > performance executing: Here, bms_singleton_member takes longer time if the relation has many columns and there's a functional dependency covering the columns at the very tail. Maybe only two are not practical for testing. Even if it doesn't impact performance detectably, if only one attribute is needed, an AttrNumber member in context will be sufficient. No bitmap operation seems required in dependency_compatible_walker and it can bail out by the second attribute. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
