Re: 64-bit sequences - Mailing list pgsql-hackers

From Paul Caskey
Subject Re: 64-bit sequences
Date
Msg-id 39611DAF.C962475B@nmxs.com
Whole thread Raw
In response to 64-bit sequences  (Paul Caskey <paul@nmxs.com>)
List pgsql-hackers
Tom Lane wrote:
> 
> Paul Caskey <paul@nmxs.com> writes:
> > Okay, cool.  Similar subject: What about making the oid 64-bit?
> 
> Let's just say you'd be opening a *much* larger can of worms there,
> because Oid is used all over the place whereas only a few routines
> know anything about sequences.

Aha!  Thanks for the warning.

> This is (or should be) on the TODO list but I wouldn't recommend it
> as your first backend programming project.
> 
> > At first glance, this seems easier to change than the sequence
> > generator, since you guys do a good job of using sizeof() and the Oid
> > typedef.
> 
> Except for all the places that assume Oid is interchangeable with int.
> Finding them is left as an exercise for the student...

Again, thanks for the warning.  :-)

Thanks for the comments on this thread.  It sounds too tricky for me to
attempt any type of 64-bit sequence at this time, especially on a 32-bit
platform.  For now, I've made my critical "id" variables type INT8, but
still use an INT4 sequence to increment them.  If/when an INT8 sequence
becomes available in the future, I will drop one in.  Otherwise if I start
getting close to the 2GB limit, I'll find a workaround to reuse holes in
the sequence.

There doesn't seem to be any problem using pgsql's int4-->int8 automatic
conversion in this way.  Hopefully I can also join on int4/int8 values
without any snags or big performance problems, although I haven't tested
that.

-- 
Paul Caskey        paul@nmxs.com        Software Engineer
New Mexico Software    5041 Indian School NE    Albuquerque, NM 87110
--


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] TOAST