Re: enabling nestedloop and disabling hashjon

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ravi Kiran <ravi(dot)kolanpaka(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: enabling nestedloop and disabling hashjon
Date: 2015-02-12 21:04:39
Message-ID: 54DD1567.8020504@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/10/15 9:29 AM, Tom Lane wrote:
> Ravi Kiran <ravi(dot)kolanpaka(at)gmail(dot)com> writes:
>> yes sir, I did try the pg_ctl reload command, but its still using the hash
>> join algorithm and not the nested loop algorithm. I even restarted the
>> server, even then its still using the hash join algorithm
>
> Does "show enable_hashjoin" say it's off? If not, I think you must've
> fat-fingered the postgresql.conf change somehow.

For future reference, posts like this belong on pgsql-performance.

The other possibility is that the query estimates are so high that the
setting doesn't matter. When you set any of the enable_* settings to
off, all that really happens is the planner adds a cost of 10M to those
nodes when it's planning. Normally that's enough to toss those plans
out, but in extreme cases the cost estimates will still come up with the
un-desired plan.

Can you post EXPLAIN ANALYZE output with the setting on and off? Or at
least plain EXLPAIN output.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-02-12 21:10:35 Re: assessing parallel-safety
Previous Message Tom Lane 2015-02-12 20:58:24 Re: gcc5: initdb produces gigabytes of _fsm files