On Thu, Jun 2, 2011 at 2:56 PM, Claudio Freire wrote:
> On Thu, Jun 2, 2011 at 4:57 PM, Kevin Grittner
> wrote:
>> And the
>> planner does take the size of work_mem and the expected data set
>> into consideration when estimating the cost of the hash join.
>
> And shouldn't it?
>
> In a gross mode
On Wed, Jun 1, 2011 at 8:10 PM, Robert James wrote:
> A query I has spends a long time on Hash Joins (and Hash Left Joins).
> I have a few questions:
>
> 1. When does Postgres decide to do a Hash Join, over another type of Join?
> 2. Do Hash Joins normally perform poorly? What can I do to speed t
On Thu, Jun 2, 2011 at 4:57 PM, Kevin Grittner
wrote:
> And the
> planner does take the size of work_mem and the expected data set
> into consideration when estimating the cost of the hash join.
And shouldn't it?
In a gross mode, when hash joins go to disk, they perform very poorly.
Maybe the pl
Robert James wrote:
> A query I has spends a long time on Hash Joins (and Hash Left
> Joins).
To submit a post which gives us enough information to help you speed
up that query, please read this page:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
> I have a few questions:
>
> 1. When
A query I has spends a long time on Hash Joins (and Hash Left Joins).
I have a few questions:
1. When does Postgres decide to do a Hash Join, over another type of Join?
2. Do Hash Joins normally perform poorly? What can I do to speed them up?
3. What can I do to enable Postgres to use a faster ty
