Re: Primary keys and composite unique keys(basic question)

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Primary keys and composite unique keys(basic question)
Дата
Msg-id CAHyXU0x6MJLC_bUo+83C59+3jLAbCDB5_qCK9SD2eHz=FHqrsQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Primary keys and composite unique keys(basic question)  (Rob Sargent <robjsargent@gmail.com>)
Список pgsql-general
On Mon, Apr 5, 2021 at 9:37 PM Rob Sargent <robjsargent@gmail.com> wrote:
>
> It's a small thing, but UUIDs are absolutely not memorizable by
> humans; they have zero semantic value.  Sequential numeric identifiers
> are generally easier to transpose and the value gives some clues to
> its age (of course, in security contexts this can be a downside).
>
> I take the above as a definite plus.  Spent too much of my life correcting others’ use of “remembered” id’s that just
happenedto perfectly match the wrong thing. 
>
> Performance-wise, UUIDS are absolutely horrible for data at scale as
> Tom rightly points out.  Everything is randomized, just awful.  There
> are some alternate implementations of UUID that mitigate this but I've
> never seen them used in the wild in actual code.
>
>
> That b-tree’s have been optimized to handle serial ints might be a considered a reaction to that popular (and
distasteful)choice.  Perhaps there should be a ’non-optimized’ option. 

It's not just the BTree, but the heap as well.   For large tables, you
are pretty much guaranteed to read a page for each record you want to
load via the key regardless of the pattern of access.  It's incredibly
wasteful regardless of the speed of the underlying storage fabric.
Very few developers actually understand this.

If computers were infinitely fast this wouldn't matter, but they aren't :-).

merlin



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

Предыдущее
От: Rob Sargent
Дата:
Сообщение: Re: Primary keys and composite unique keys(basic question)
Следующее
От: Mihalidesová Jana
Дата:
Сообщение: Upgrade from 11.3 to 13.1 failed with out of memory