Re: Hash index build patch has *worse* performance at small table sizes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hash index build patch has *worse* performance at small table sizes
Date
Msg-id 27492.1214095076@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hash index build patch has *worse* performance at small table sizes  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.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'llthrash horribly.  To prevent that scenario, we can sort the    * tuples by (expected) bucket number.  However,
sucha sort is useless    * overhead when the index does fit in RAM.  We choose to sort if the    * initial index size
exceedseffective_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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Hash index build patch has *worse* performance at small table sizes
Next
From: Bruce Momjian
Date:
Subject: PG Pool Party (formerly MomjiCon) date set