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:

Reply via email to