Re: PrivateRefCount (for 8.3)

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PrivateRefCount (for 8.3)
Date: 2006-11-27 19:42:33
Message-ID: 200611271942.kARJgXX24648@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> > 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.
>
> And at 2000 connections we waste RAM the size of shared_buffers... that
> isn't something to easily ignore.
>
> > 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.
>
> int8 still seems like overkjll. When will the ref counts go above 2 on a
> regular basis? Surely refcount=2 is just chance at the best of times.
>
> Refcount -> 2 bits per value, plus a simple overflow list? That would
> allow 0,1,2 ref counts plus 3 means look in hashtable to find real
> refcount.

At two bits, would we run into contention for the byte by multiple
backends?

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-11-27 19:46:53 Re: Day and month name localization uses wrong
Previous Message Tom Lane 2006-11-27 19:39:40 Re: PrivateRefCount (for 8.3)