From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extending varlena |
Date: | 2008-08-19 04:16:54 |
Message-ID: | 1219119414.5343.945.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2008-08-18 at 23:43 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > Probably also using a separate Sequence to allocate numbers rather than
> > using up all the Oids on LOs would be a good plan.
>
> Well, assuming that your Large Objects are actually Large, you aren't
> going to need as many OIDs as all that ;-)
>
> However: I was chewing on this point a few days ago, and it seemed to me
> that essentially duplicating the functionality of the OID generator
> wasn't likely to be a win. What seems more practical is to extend the
> internal next-OID counter to 64 bits, and allow callers to get either
> the full 64 bits or just the lowest 32 bits depending on what they need.
> This change would actually be entirely transparent to 32-bit callers,
> and the extra cycles to manage a 64-bit counter would surely be lost in
> the noise compared to acquiring/releasing OidGenLock.
Sounds very cool.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-08-19 04:18:41 | Proposed Resource Manager Changes |
Previous Message | Tom Lane | 2008-08-19 03:43:44 | Re: Extending varlena |