"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> Under specific conditions, I propose to replace the array with a hash
> table, designed with a custom hash function that would map the pins held
> onto just 16 hash buckets.
Most likely a waste of development effort --- have you got any evidence
of a real effect here? With 200 max_connections the size of the arrays
is still less than 10% of the space occupied by the buffers themselves,
ergo there isn't going to be all that much cache-thrashing compared to
what happens in the buffers themselves. You're going to be hard pressed
to buy back the overhead of the hashing.
It might be interesting to see whether we could shrink the refcount
entries to int16 or int8. We'd need some scheme to deal with overflow,
but given that the counts are now backed by ResourceOwner entries, maybe
extra state could be kept in those entries to handle it.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2006-11-27 18:51:10|
|Subject: Re: Configuring BLCKSZ and XLOGSEGSZ (in 8.3) |
|Previous:||From: Jim C. Nasby||Date: 2006-11-27 18:30:52|
|Subject: Re: [CORE] RC1 blocker issues|