Re: Performance implications of creating many, many sequences

Поиск
Список
Период
Сортировка
От Michael Gardner
Тема Re: Performance implications of creating many, many sequences
Дата
Msg-id 21A068C3-BF98-43D6-922B-E3B179D7CB47@gmail.com
обсуждение исходный текст
Ответ на Re: Performance implications of creating many, many sequences  (Craig Ringer <craig@postnewspapers.com.au>)
Ответы Re: Performance implications of creating many, many sequences  (Craig Ringer <craig@postnewspapers.com.au>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: rule which unpredictable modify a sequence number
Следующее
От: "Massa, Harald Armin"
Дата:
Сообщение: createlang plpythonu fails on 64bit windows