EG
банальная задача есть id номер, для каждой записи в таблицу, таблица партицированная. Необходимо чтоб id был уникальным.
Size: a a a
2021 January 11
VY
повесить pk на отдельный сиквенс
PK и последовательности не связаны никак
EG
Подскажите в какую сторону копать?
VY
Evgeniy Grygoriev
банальная задача есть id номер, для каждой записи в таблицу, таблица партицированная. Необходимо чтоб id был уникальным.
у меня встречный вопрос: вот вы внедрили секции, поделили таблицу на кусочки меньшего размера с заранее известными границами. цель — удобство управления и минимизация IO за счёт работы не со всеми данными, а с ограниченными диапазонами.
и теперь вы хотите завести себе глобальный PK, который будет индексировать весь диапазон данных. (читайте — вы отменяете все плюшки партиционирования.)
вопрос — какая цель?
и теперь вы хотите завести себе глобальный PK, который будет индексировать весь диапазон данных. (читайте — вы отменяете все плюшки партиционирования.)
вопрос — какая цель?
EG
у меня встречный вопрос: вот вы внедрили секции, поделили таблицу на кусочки меньшего размера с заранее известными границами. цель — удобство управления и минимизация IO за счёт работы не со всеми данными, а с ограниченными диапазонами.
и теперь вы хотите завести себе глобальный PK, который будет индексировать весь диапазон данных. (читайте — вы отменяете все плюшки партиционирования.)
вопрос — какая цель?
и теперь вы хотите завести себе глобальный PK, который будет индексировать весь диапазон данных. (читайте — вы отменяете все плюшки партиционирования.)
вопрос — какая цель?
При аналитике с разных секций данные смешиваются
VY
можно сделать для всех секций
DEFAULT nextval('my_seq')VY
Evgeniy Grygoriev
При аналитике с разных секций данные смешиваются
а что мешает в аналитику добавить ( partitioning_key + id ) как признак уникальности?
SG
Postgres всё еще не поддерживает глобальный индекс на партиции?
VY
Postgres всё еще не поддерживает глобальный индекс на партиции?
зачем он вам?!
SG
Если у меня таблица заказов разбита по штатам, а курьер получает только номер заказа, то поиск с глобальным индексом будет чуть быстрее
EG
зачем он вам?!
То есть этого функционала нет в принципе
VY
есть этот функционал: https://www.postgresql.org/docs/current/sql-createtable.html
When establishing a unique constraint for a multi-level partition hierarchy, all the columns in the partition key of the target partitioned table, as well as those of all its descendant partitioned tables, must be included in the constraint definition.
VY
Если у меня таблица заказов разбита по штатам, а курьер получает только номер заказа, то поиск с глобальным индексом будет чуть быстрее
ещё раз — вы поделили таблицу на кусочки ради оптимизации. и вы сразу отменяете эту оптимизацию через глобальный индекс (не говоря про гемморой у админов при работе с партициями на такой таблице).
добавить штат из заказа в заявку курьеру не сложно. а номер + штат == прыжок в нужный индекс нужной секции
добавить штат из заказа в заявку курьеру не сложно. а номер + штат == прыжок в нужный индекс нужной секции
EG
ещё раз — вы поделили таблицу на кусочки ради оптимизации. и вы сразу отменяете эту оптимизацию через глобальный индекс (не говоря про гемморой у админов при работе с партициями на такой таблице).
добавить штат из заказа в заявку курьеру не сложно. а номер + штат == прыжок в нужный индекс нужной секции
добавить штат из заказа в заявку курьеру не сложно. а номер + штат == прыжок в нужный индекс нужной секции
Ну допустим, мы не используем такие данные на постоянной основе. Это выборка раз в месяц, но она нужна.
То получается всего-то надо добавить ALTER TABLE the_table ADD CONSTRAINT constraint_name UNIQUE (thecolumn);
То получается всего-то надо добавить ALTER TABLE the_table ADD CONSTRAINT constraint_name UNIQUE (thecolumn);
VY
Evgeniy Grygoriev
Ну допустим, мы не используем такие данные на постоянной основе. Это выборка раз в месяц, но она нужна.
То получается всего-то надо добавить ALTER TABLE the_table ADD CONSTRAINT constraint_name UNIQUE (thecolumn);
То получается всего-то надо добавить ALTER TABLE the_table ADD CONSTRAINT constraint_name UNIQUE (thecolumn);
мне сама постановка данного вопроса видится странной:
- у вас нет PK на таблиц?
- тогда кто у вас ответственнен за базу и данные?
- каким образом у вас осуществляется проектирование схемы данных?
если коротко: да, надо добавить PK. но это почти 100% не выйдет, если его сейчас нет, из-за дубликатов
- у вас нет PK на таблиц?
- тогда кто у вас ответственнен за базу и данные?
- каким образом у вас осуществляется проектирование схемы данных?
если коротко: да, надо добавить PK. но это почти 100% не выйдет, если его сейчас нет, из-за дубликатов
EG
Учусь , база не боевая. PK есть.
SG
ещё раз — вы поделили таблицу на кусочки ради оптимизации. и вы сразу отменяете эту оптимизацию через глобальный индекс (не говоря про гемморой у админов при работе с партициями на такой таблице).
добавить штат из заказа в заявку курьеру не сложно. а номер + штат == прыжок в нужный индекс нужной секции
добавить штат из заказа в заявку курьеру не сложно. а номер + штат == прыжок в нужный индекс нужной секции
А какие там админские проблемы? Мы же не собираемся дропать штаты?
VY
А какие там админские проблемы? Мы же не собираемся дропать штаты?
да-да… частая задача: отцепить партицию+что-то сделать+подцепить обратно. помню одна такая задачка занимала 20-30 минут, но планировали downtime на 8+ часов и всю ночь проклинали идиотов, которые насовали кургом глобальных индексов.
SG
да-да… частая задача: отцепить партицию+что-то сделать+подцепить обратно. помню одна такая задачка занимала 20-30 минут, но планировали downtime на 8+ часов и всю ночь проклинали идиотов, которые насовали кургом глобальных индексов.
Одну партицию? Не все сразу?
VY
одну партицию