Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why?
В списке pgsql-performance по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: HashJoin order, hash the large or small table? Postgres likes to hash the big one, why? |
| Дата | |
| Msg-id | 1532.1287459825@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | HashJoin order, hash the large or small table? Postgres likes to hash the big one, why? (Scott Carey <scott@richrelevance.com>) |
| Ответы |
Re: HashJoin order, hash the large or small table?
Postgres likes to hash the big one, why?
|
| Список | pgsql-performance |
Scott Carey <scott@richrelevance.com> writes:
> I consistently see HashJoin plans that hash the large table, and scan
> the small table.
Could we see a self-contained test case? And what cost parameters are
you using, especially work_mem?
> This is especially puzzling in some cases where I have 30M rows in the big table and ~ 100 in the small... shouldn't
ithash the small table and scan the big one?
Well, size of the table isn't the only factor; in particular, a highly
nonuniform distribution of the key value will inflate the cost estimate
for using a table on the inner size of the hash. But the example you
show here seems a bit extreme.
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера