Re: Horribly slow hash join - Mailing list pgsql-performance

From Tom Lane
Subject Re: Horribly slow hash join
Date
Msg-id 19739.1082303195@sss.pgh.pa.us
Whole thread Raw
In response to Re: Horribly slow hash join  (Greg Stark <gsstark@mit.edu>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Horribly slow hash join
Next
From: Dennis Bjorklund
Date:
Subject: Re: Horribly slow hash join