Re: Could postgres12 support millions of sequences? (like 10 million)
От | Rob Sargent |
---|---|
Тема | Re: Could postgres12 support millions of sequences? (like 10 million) |
Дата | |
Msg-id | 0D8F2D62-C0E4-4D6C-B77C-9A2FEB78898C@gmail.com обсуждение исходный текст |
Ответ на | Re: Could postgres12 support millions of sequences? (like 10 million) ("Peter J. Holzer" <hjp-pgsql@hjp.at>) |
Ответы |
Re: Could postgres12 support millions of sequences? (like 10 million)
|
Список | pgsql-general |
> On Mar 20, 2020, at 4:59 PM, Peter J. Holzer <hjp-pgsql@hjp.at> wrote: > > On 2020-03-19 16:48:19 -0700, David G. Johnston wrote: >> First, it sounds like you care about there being no gaps in the records you end >> up saving. If that is the case then sequences will not work for you. > > I think (but I would love to be proven wrong), that *nothing* will work > reliably, if > > 1) you need gapless numbers which are strictly allocated in sequence > 2) you have transactions > 3) you don't want to block > > Rationale: > > Regardless of how you get the next number, the following scenario is > always possible: > > Session1: get next number > Session2: get next nummber > Session1: rollback > Session2: commit > > At this point you have a gap. > > If you can afford to block, I think a simple approach like > > create table s(id int, counter int); > ... > begin; > ... > update s set counter = counter + 1 where id = $whatever returning counter; > -- use counter > commit; > > should work. But that effectively serializes your transactions and may > cause some to be aborted to prevent deadlocks. > > hp OP has said small gaps are ok. To me that says the requirement is capricious but we haven’t heard the rationale for therequirement yet (or I missed it) Aside: apologies for the empty message earlier
В списке pgsql-general по дате отправления: