| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | Bill Moran <wmoran(at)potentialtech(dot)com> |
| Cc: | db(dot)subscriptions(at)shepherdhill(dot)biz, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Serial Jumping |
| Date: | 2009-01-27 05:24:23 |
| Message-ID: | 497E9A87.50305@postnewspapers.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Bill Moran wrote:
> db(dot)subscriptions(at)shepherdhill(dot)biz wrote:
>> Hi,
>>
>> I have a table with BIG SERIAL field as Primary KEY. During high load,
>> entries in the BIG SERIAL field are jumped. One could see a row with
>> 1367 and expecting the next INSERT to be 1368, one would end up
>> getting 1369.
>>
>> Please is this normal?
>
> If transactions rollback, the serial value assigned during the rolled
> back transaction is skipped. This has been discussed many times, it's
> a tradeoff between losing some #s now and again and taking a huge
> performance and code complexity hit to avoid it.
>
> If you absolutely need consecutive #s, then serial is not for you and
> you should implement your own method of acquiring sequential numbers.
You should also understand the several LARGE downsides to doing so. See
repeated past mailing list discussion.
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | A. Kretschmer | 2009-01-27 06:10:18 | Re: Serial Jumping |
| Previous Message | Bill Moran | 2009-01-27 05:14:48 | Re: Serial Jumping |