Re: hash join vs nested loop join

Frankly, at 12 microseconds per matched pair of rows, I think
> you're doing OK.
>
> This plan is the good one, I want the indexscan nested loop join and this
is only achieved after making all these costing factors change. Before
that, it was hash join and was very slow.

However, I'm worried about the config changes being too 'extreme', i.e.
both sequential I/O and random I/O have the same cost and being only 0.1.
So, I was more wondering why I have to make such dramatic changes to
convince the optimiser to use NL join instead of hash join. And also, I'm
not sure what impact will these changes have on other queries yet. e.g.
will a query that's fine with hash join now choose NL join and runs slower?