Re: Performance implications of creating many, many sequences - Mailing list pgsql-general

From Michael Gardner
Subject Re: Performance implications of creating many, many sequences
Date
Msg-id 21A068C3-BF98-43D6-922B-E3B179D7CB47@gmail.com
Whole thread Raw
In response to Re: Performance implications of creating many, many sequences  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: Performance implications of creating many, many sequences  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-general
On Oct 22, 2010, at 11:03 PM, Craig Ringer wrote:

> Instead, maintain a counter, either in the main customer record or in an associated (customer_id, counter) side table
ifyou want to reduce potential lock contention. Write a simple SQL function that uses an UPDATE ... RETURNING statement
tograb a new ID from the counter and increment it. Use that function instead of 'nextval(seqname)' when you want an ID.
TheUPDATE will take a lock out on the customer row (or side-table row if you did it that way) that'll prevent anyone
elseupdating it until the transaction commits or rolls back. 

Thanks for the suggestion. It seems like there should be a safe way to use max() instead of a separate counter though,
aslong as I can guarantee that invoice numbers never change and invoices are never deleted. Right? 

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: rule which unpredictable modify a sequence number
Next
From: "Massa, Harald Armin"
Date:
Subject: createlang plpythonu fails on 64bit windows