Re: Horribly slow hash join

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Horribly slow hash join
Дата
Msg-id 19739.1082303195@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Horribly slow hash join  (Greg Stark <gsstark@mit.edu>)
Список pgsql-performance
Greg Stark <gsstark@mit.edu> writes:
> Eh? Oh, negative numbers? So low^high^sign.

[ thinks about it... ]  Yeah, that would work.  We can't backpatch it
without breaking existing hash indexes on int8, but it'd be reasonable
to change for 7.5 (since at the rate things are going, we won't have
pg_upgrade for 7.5 anyway...)

> I wonder if it makes sense to have check the hash distribution after
> generating the table and if it's bad then throw it away and try again with a
> different hash function. The "different hash function" would probably just be
> a seed value changing. Probably way overkill though.

Yeah, it'd be a pain trying to get all the type-specific hash functions
doing that.  I'm also unconvinced that a simple change of seed value
would necessarily make the distribution better.  In the worst case, if
the real problem is that all the input values are identical, you can
reseed all day long and it won't fix it.

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Horribly slow hash join
Следующее
От: Dennis Bjorklund
Дата:
Сообщение: Re: Horribly slow hash join