Re: Horribly slow hash join

Поиск
Список
Период
Сортировка
От Marcos Martínez(R)
Тема Re: Horribly slow hash join
Дата
Msg-id 001001c424bb$7fb83740$0564a8c0@lobeira
обсуждение исходный текст
Ответ на Horribly slow hash join  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-performance
I didn't follow the conversation from the begining, bu I imagine that you
could improve
performance using the value (work_units % (2^32) ) instead of work_units.
You could even make an index on this value. Like that, the HASH function
will work well. This is not a good solution, but ...

For example.

create index ind1 on table1 ( work_units % (2^32) );

create index ind1 on table2 ( work_units % (2^32) );

Select * from table1 join table2 on (table1.work_units % (2^32) ) =
(table2.work_units % (2^32) )


----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Jim C. Nasby" <jim@nasby.net>
Cc: <pgsql-performance@postgreSQL.org>
Sent: Saturday, April 17, 2004 6:08 PM
Subject: Re: [PERFORM] Horribly slow hash join


> [ resending because I fat-fingered the cc: to the list ]
>
> I see the problem: all the entries in your work_units column have the
> low 32 bits equal to zero.
>
> regression=# select distinct work_units % (2^32)::bigint from
Trank_work_overall;
>  ?column?
> ----------
>         0
> (1 row)
>
> The hash function for int8 only takes the low word into account, so all
> of the entries end up on the same hash chain, resulting in worst-case
> behavior.  This applies to both your hash join and hash aggregate cases.
>
> We could change the hash function, perhaps, but then we'd just have
> different cases where there's a problem ... hashing will always fail on
> *some* set of inputs.  (Also, I have been harboring some notions of
> supporting cross-type hash joins for integer types, which will not work
> unless small int8 values hash the same as int4 etc.)
>
> I guess the real issue is why are you encoding work_units like that?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
>                http://archives.postgresql.org



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

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