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
allow
incremental allocation but set a hard limit on the number of
entries
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 --
then
you don't have the cost of having to split buckets later as it
grows.
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:
http://www.postgresql.org/mailpref/pgsql-hackers
