Re: Hash index build patch has *worse* performance at small table sizes

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Did we ever do anything about this?

Seems to be in there in CVS HEAD:

/*
* If we just insert the tuples into the index in scan order, then
* (assuming their hash codes are pretty random) there will be no locality
* of access to the index, and if the index is bigger than available RAM
* then we'll thrash horribly. To prevent that scenario, we can sort the
* tuples by (expected) bucket number. However, such a sort is useless
* overhead when the index does fit in RAM. We choose to sort if the
* initial index size exceeds effective_cache_size.
*
* NOTE: this test will need adjustment if a bucket is ever different
* from one page.
*/
if (num_buckets >= (uint32) effective_cache_size)
buildstate.spool = _h_spoolinit(index, num_buckets);
else
buildstate.spool = NULL;

regards, tom lane