Спасибо.

> кстати, зачем

Увидел такого рода запрос, где случайно в from добавили доп. таблицу очень большого размера.
В итоге на pg9.5 делается seq. scan по этой таблице и запрос работает в 30 000 медленнее.

Стало интересно, как ведёт себя pg в этом случае и что может пойти не так.

Ваш комментарий взят из статьи про CTE. Я бы предположил, что это может относиться только к CTE, когда в разных sub-statement-ах обновляется одна и та же строка.

Добрый день, хочется создать такое хранилище

название столбца - кардинальность (тип значения)
(A) ARTICLE - 500000 (uuid)
(R) REGION - 200 (uuid)
(S) SIZE - 150 (decimal)
(C) COUNT: 300k (int) т.е. это общее количество записей будет.

Запросы к нему планируются:
 По Article (и по диапазону 50 значений) -> на выходе словарь где ключ регион, а значение общий COUNT по всем SIZE
 по Region, на выходе словарь, где ключ A, значение - общий COUNT по всем Size
 и др. агрегирующие в разных комбинациях.

Обновление тоже будет частое, операций 100 в минуту. (но если это критично, можно попобовать реже)

В подкастиках слышал, что postgres если правильно настроить под свою задачу всегда может выручить. Вот как на ваш взгляд, можно это через реляционку делать? какие индексы, какие настройки порекомендуете?

Кейс не редкий (типичный интернет магазин), если не postgres, то подскажите что тут можно использовать

Я почти ничего не понял по схеме, но полмиллона записей и полтора апдейта в секунду — это ерунда даже для свежеустановленного постгреса, можете брать.

Article. Артикул, е-мое.

> Вот как на ваш взгляд, можно это через реляционку делать?

постгрес как раз под ваш случай, так что подойдет

> какие индексы, какие настройки порекомендуете?

для начала можно обойтись теми что создаются при указании primary ключей, дальше уже ориентироваться по тому какие запросы будут в бд

ну и uuid - десять раз подумайте насколько оно оправдано у вас, и нет ли возможности заменить его на bigint

Вроде бы uuid вполне быстрый, если только не хранить его в виде строк. При таких нагрузках разницы не должно быть.

Тогда см. комментарии про TM_SelfModified в src/backend/executor/nodeModifyTable.c

* The target tuple was already updated or deleted by the
* current command, or by a later command in the current
* transaction.  The former case is possible in a join UPDATE
* where multiple tuples join to the same target tuple. This
* is pretty questionable, but Postgres has always allowed it:
* we just execute the first update action and ignore
* additional update attempts.

Всё равно неизвестно, какое из обновлений в таком случае будет первым (потому и questionable, я думаю), так что какой смысл это знать? ;) Исправить ошибку в запросе, да и всё.

Вообще-то, "должна" (т.е. теоретически) и нередка на практике.
А уж что в benchmarks можно намерять — вообще жуть. ;)

Добрый день, подскажите как дропнуть репликацию в 9.6, при использовании select pg_drop_replication_slot('slot_name'); - просит имя слота репликации, но имя слота я не вижу

задача остановить репликацию чтобы сделать бекап, построить индекс и опять запустить репликацию

как индекс построить и запустить репликацию уже знаю

1) Остановить реплику.
2) pg_xlog_replay_pause - но это скорее поставит на паузу, нежели остановит wal sender/receiver.

А зачем останавливать репликацию для бекапа?

нет надо остановить, потому что прод, чтобы данные не улетели на слейв

сделать бекап (на всякий случай - если что пойдёт не так) и потом построить индекс по столбцу

чтобы откатиться, делать будут другие, могут накосячить

тогда наверно достаточно pg_xlog_replay_pause. С большой вероятностью всё пройдёт успешно, поэтому sender/receiver лучше не останавливать.

И да, перенастроить репликацию чтобы она использовала replication слоты )

собрал стенд пишу инструкцию, что не так ?