Re: hash join vs nested loop join

Поиск
Список
Период
Сортировка
От Huan Ruan
Тема Re: hash join vs nested loop join
Дата
Msg-id CAD1stZuf2Xw1RmDaZkNVZeq6MUcyPjYP8HVhd+6rSomX__ij1g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: hash join vs nested loop join  ("Kevin Grittner" <kgrittn@mail.com>)
Список pgsql-performance
Дерево обсуждения



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? 

В списке pgsql-performance по дате отправления:

Предыдущее
От: Richard Neill
Дата:
Сообщение: Re: Why does the query planner use two full indexes, when a dedicated partial index exists?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Why does the query planner use two full indexes, when a dedicated partial index exists?