On Mon, 2008-08-18 at 23:43 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
