At Thu, 6 Apr 2017 13:10:48 +1200, David Rowley <david.rowley@2ndquadrant.com> wrote in
<CAKJS1f8Um=BvRmgcb3u6ze1q1xL7A1VKTVF9s2R1_UfRqx8q5w@mail.gmail.com>
> On 6 April 2017 at 13:05, David Rowley <david.rowley@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.rowley@2ndquadrant.com> wrote in
<CAKJS1f_gB=gyZn8wMw0v8uCKD1nYeWyNYCXKz=+Oo0yR4RRyiA@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
