Hash index build patch has *worse* performance at small table sizes
in [PgSql]
|
Prev: Hash index build patch has *worse* performanceat small table sizes
Next: Proposal of SE-PostgreSQL patches [try#2]
From: Tom Lane on 21 Jun 2008 20:37 Bruce Momjian <bruce(a)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'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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |