Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?

From: pasman pasmański <pasman(dot)p(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
Date: 2011-04-15 15:15:06
Message-ID: BANLkTinVrHwVu_8-uqqc8U8zMGU6ihrRBg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

hi.

>I think you're missing the point, which is that all the hash work is
>just pure overhead in such a case (and it is most definitely not
>zero-cost overhead). You might as well just do a nestloop join.
>Hashing is only beneficial to the extent that it allows a smaller subset
>of the inner relation to be compared to each outer-relation tuple.
>So I think biasing against skew-distributed inner relations is entirely
>appropriate.

Scanning smaller relation first is better with cursors.
First rows from query are returned faster in this case.
Maybe add this optimization for cursors only?

------------
pasman

Browse pgsql-performance by date

  From Date Subject
Next Message Mark Williams 2011-04-15 17:17:32 Bad Query Plan with Range Query
Previous Message Václav Ovsík 2011-04-15 07:59:26 Re: poor execution plan because column dependence