On 31.03.2011 21:23, Kevin Grittner wrote:
Dan Ports<d...@csail.mit.edu>  wrote:
On Thu, Mar 31, 2011 at 11:06:30AM -0500, Kevin Grittner wrote:
The only thing I've been on the fence about is whether it
makes more sense to allocate it all up front or to continue to
incremental allocation but set a hard limit on the number of
allocated for each shared memory HTAB.  Is there a performance-
related reason to choose one path or the other?

Seems like it would be marginally better to allocate it up front --
you don't have the cost of having to split buckets later as it

The attached patch should cover that.

That's not enough. The hash tables can grow beyond the maximum size you specify in ShmemInitHash. It's just a hint to size the directory within the hash table.

We'll need to teach dynahash not to allocate any more entries after the preallocation. A new HASH_NO_GROW flag to hash_create() seems like a suitable interface.

  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to