Re: Could be improved point of UPSERT

Поиск
Список
Период
Сортировка
От Yourfriend
Тема Re: Could be improved point of UPSERT
Дата
Msg-id CABL_R4O4wq171XyHQd-iKBzxcK3u4TvZVZ9R=RBzpFLbdwq6YQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Could be improved point of UPSERT  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers

For the most cases I mentioned, we don't request a strict gapless sequence for the Invoice ID, the essential requirement is unique.
We just hope that there is no obviously gap in most situations. 
From the test of UPSERT, there are quite a few chances to generate a big gap when UPSERT multi records. 
However, the result of UPSERT is acceptable, and I do love this function. So, it's a suggestion only.

Anyway, thanks a lot for the detail explanation. 

Regards,

Daojing Zhou.




On Wed, Jul 15, 2015 at 3:23 PM, Peter Geoghegan <pg@heroku.com> wrote:
On Wed, Jul 15, 2015 at 12:01 AM, Yourfriend <doudou586@gmail.com> wrote:
> for example, SO201507_1001, PO201503_1280, etc.
>
> As these IDs would be the most important attribute to the business, so, we
> hope there is no gap for the IDs.

That's a requirement I've heard a number of times before. If you're
relying on a sequence for this purpose, your application is already
broken [1]. UPSERT need not be involved at all.

[1] http://www.varlena.com/GeneralBits/130.php
--
Peter Geoghegan

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

Предыдущее
От: Atri Sharma
Дата:
Сообщение: Re: Memory Accounting v11
Следующее
От: Andres Freund
Дата:
Сообщение: Re: security labels on databases are bad for dump & restore