Eu tenho um sistema que usa o formato UUID7 proposto para seus valores uuid. UUID7 tem carimbo de data/hora codificado em seu valor. O PostgreSQL documenta como as cláusulas ORDER BY funcionam com o tipo de dados UUID?
https://www.postgresql.org/docs/current/datatype-uuid.html Não há notas sobre classificação aqui.
lab7=# SELECT resource_id, uuid, created_timestamp from resource where "name" in ('ABC000004',
'ABC000003') order by uuid, "name" desc;
resource_id | uuid | created_timestamp
-------------+--------------------------------------+----------------------
------
17704701 | 018ec350-6976-79d5-b0f5-41af99b98fa4 | 2024-04-09 14:43:30.6
09909
17704718 | 018ec353-ee50-7765-9e8b-3ebf22654662 | 2024-04-09 14:47:21.3
78086
Comparando os caracteres mais à esquerda (assumindo que se trata de uma string), esperaria que 018ec353 estivesse no conjunto de resultados antes de 018ec350. Como isso não é armazenado como uma string, essa suposição pode ser ingênua.
Em termos de desempenho, a classificação por resource_id aqui ou create_timestamp tem melhor desempenho, mas eu esperaria que a classificação no resource_id de incremento exclusivo, no uuid globalmente exclusivo e nocreate_timestamp estivessem todos alinhados. (A entrada criada mais recente é classificada primeiro quando ordenada por descrição)
Há algum detalhe sobre como essa classificação é realizada e por que minhas suposições estão erradas?
Este é um problema XY™ - você parece assumir que o
desc
modificador se aplica a todas as colunas daorder by
cláusula, enquanto se aplica apenas a"name"
euuid
é classificado em ordem crescente por padrão.Para responder à questão real, as alterações propostas à RFC 4122 incluem esta declaração:
Postgres compara UUIDs como tal , usando
memcmp()
.