Re: Best approach for a "gap-less" sequence

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Best approach for a "gap-less" sequence
Дата
Msg-id b42b73150608171307v1d1a6346h8a1d2b175212ba95@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Best approach for a "gap-less" sequence  (Brad Nicholson <bnichols@ca.afilias.info>)
Ответы Re: Best approach for a "gap-less" sequence  (Scott Marlowe <smarlowe@g2switchworks.com>)
Re: Best approach for a "gap-less" sequence  (Brad Nicholson <bnichols@ca.afilias.info>)
Re: Best approach for a "gap-less" sequence  ("Dawid Kuroczko" <qnex42@gmail.com>)
Список pgsql-general
On 8/17/06, Brad Nicholson <bnichols@ca.afilias.info> wrote:

> > > Hmm, I think you are wrong.  There is a SELECT ... FOR UPDATE;
> > > The first-to-obtain the gapless sequence transaction will establish
> > > a lock onthe "tax_id" row.  The other transaction will block until
> > > the first transaction finishes (and the row is updated) and will
> > > establish the row lock on it.
> >
> > yes, you are right...i didnt think the problem through properly.
>
> Lets just hope the performance on a concurrent system is not a
> requirement of such a system...
>

right, if the transations are long running, there is a big problem as
they are serialized around access to the sequence.  however this is
better than the control record approach because control record have
problems with mvcc bloat.  concurrent performance will of course be
awful.

a good compomise in some cases is to save off canceled transactions
ids' in a free list   you would still have to deal with transactions
that were not gracefully cancelled though.

merlin

В списке pgsql-general по дате отправления:

Предыдущее
От: Michael Fuhr
Дата:
Сообщение: Re: [NOVICE] DB insert Error
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: Best approach for a "gap-less" sequence