On 6 April 2017 at 19:50, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > At Thu, 6 Apr 2017 18:59:35 +1200, David Rowley > <david.row...@2ndquadrant.com> wrote in > <CAKJS1f-yrLizV5N_-r1o4vemuZBTJd8EzwPyx2QG=F6891++=g...@mail.gmail.com> >> On 6 April 2017 at 18:03, Kyotaro HORIGUCHI >> <horiguchi.kyot...@lab.ntt.co.jp> wrote: >> > 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'm not all that sure why the number of columns in the relation has >> relevance to the performance of find_relation_from_clauses(). The >> bms_get_singleton_member() is checking which relations are part of the >> RestrictInfo, nothing related to columns in relations. >> Perhaps you meant clauses in the clauses list? Which does not really >> have all that much to do with the number of columns in the relation >> either. > > Sorry, it's number of relations, not columns. I'm not sure up to > how many relations we practically should consider but anyway it > is extra burden to every call to clauselist_selectivity. We > should avoid calling find_relation_from_clauses as far as > possible or do the same in more simple way. However I'm not sure > more precise exclusion is possible or not, I thinks that the case > of jointype != JOIN_INNER can be exluded.
Well, I imagine queries with >= 32 relations are not planning very quickly as of today already. I understand what you mean when you speak of attributes, as we could constantly be looking for the 1400's attribute which is many loops into a bms_get_singleton_member() call. I can't imagine we'll even flow over the first word in a bitmap set in 99% of cases with clause_relids. In any case, even if there's a giant chain of clauses in the the 'clauses' list, we'll bail out on the first join qual anyway, since it won't be a singleton clause_relid. I'd say if you can come up with a test case where you can measure the impact of this, then let's discuss more. Otherwise we're stepping back into the territory that Tom warned me about a few emails up.... Premature Optimisation. I'm not walking down there again, I only just got back. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers