в таблице миалитем - хранится очередь писем и каой у них статус. в таблице миалконнектор - ранится на какой ящик приехало письмо

Чуть длиннее id, не находишь?..)

нет. не нахожу

так у тебя столбец integer, а в запросе ты ему строку передаёшь

ааа, вот я ступит ))

Притом, что сегодня он запускал автовакуум/автоаналайз на эту таблицу

Покажите запрос и EXPLAIN ANALYZE (и лучше сразу \d участвующих таблиц). Второе можно на https://explain.depesz.com/

Покажите запрос и EXPLAIN ANALYZE (и лучше сразу \d участвующих таблиц). Второе можно на https://explain.depesz.com/

Table "public.red_messages" Column | Type | Collation | Nullable | Default --------------------+--------------------------+-----------+----------+--------- id | uuid | | not null | ourReceiverId | character varying(255) | | | providerReceiverId | character varying(255) | | | providerMessageId | character varying(255) | | | sender | character varying(255) | | not null | tag | character varying(255) | | not null | provider | character varying(255) | | not null | status | integer | | not null | payload | jsonb | | not null | startAt | timestamp with time zone | | not null | now() sentAt | timestamp with time zone | | | publicId | integer | | not null | createdAt | timestamp with time zone | | not null | updatedAt | timestamp with time zone | | not null | errorMessage | character varying(255) | | | priority | integer | | not null | 0 receiverPhone | character varying(255) | | | lifetime | integer | | not null | 86400 Indexes: "red_messages_pkey" PRIMARY KEY, btree (id) "red_messages_priority" btree (priority) "red_messages_provider_message_id" btree ("providerMessageId") "red_messages_sender" btree (sender) "red_messages_status" btree (status) "red_messages_tag" btree (tag) Foreign-key constraints: "red_messages_publicId_fkey" FOREIGN KEY ("publicId") REFERENCES publics(id)

https://explain.depesz.com/s/2KsZ

SELECT "ctid" FROM "red_messages" AS "red_message" WHERE "red_message"."status" = 0 AND "red_message"."startAt" <= CURRENT_TIMESTAMP ORDER BY "red_message"."priority" DESC LIMIT 30;

Как-то так

(AS добавила ORM)

Это уже после VACUUM ANALYZE ручного

До него осталась json-версия эксплейна

Как-то так

Это, насколько я вижу, т.н. early abort plan. (см. https://www.postgresql.org/message-id/541A2335.3060100@agliodbs.com , если интересны детали.) Но, вкратце, дело в том, что у Вас нет идеального индекса для данного запроса, во-первых, и, возможно, что-то не так со статистикой, во-вторых: (cost=0.43..3505.44 rows=1344 width=10) (actual time=0.136..0.136 rows=0 loops=1) — Это очень большая ошибка в оценке. Проще будет создать подходящий индекс (чтобы не заставлять планировщик гадать, выбирая среди менее подходящих).

То есть лучше подсказать индексу, в какую сторону будет делаться ORDER BY?

А что за тула?

А что за тула?

pev: http://tatiyants.com/pev/

Это уже после VACUUM ANALYZE ручного

Кстати, про оценку: может, у Вас status коррелирует с startAt?

Кстати, про оценку: может, у Вас status коррелирует с startAt?

В каком плане?

То есть лучше подсказать индексу, в какую сторону будет делаться ORDER BY?

Причём тут это? ;) PostgreSQL может сканировать индексы в любом направлении... Я имел в виду что-то такое: CREATE INDEX [CONCURRENTLY] ON red_messages(status, startAt);

В каком плане?

В этом: https://explain.depesz.com/s/2KsZ

Хм, действительно, на startAt же вообще ничего не висит, ни в каком виде

Попробую сейчас такой вариант, спасибо!

Хм, действительно, на startAt же вообще ничего не висит, ни в каком виде

Кстати, если Вы просто на startAt повесите, проблема со стабильностью плана, скорее всего, останется. Т.е. PostgreSQL после очередного ANALYZE может "переключаться" на другой индекс. Тут у Вас и так estimations очень косые, так что проще подстраховаться, IMHO. ;)

Кстати, если Вы просто на startAt повесите, проблема со стабильностью плана, скорее всего, останется. Т.е. PostgreSQL после очередного ANALYZE может "переключаться" на другой индекс. Тут у Вас и так estimations очень косые, так что проще подстраховаться, IMHO. ;)

Я сделал на два поля, как вы и написали)

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

Ибо сейчас он по-прежнему использует индекс на status

Ибо сейчас он по-прежнему использует индекс на status

Нисколько. ;) Я не заметил, что в Вашем запросе ORDER BY не по startAt, а по другому полю...

Ну, переделать недолго, хех

Ну, переделать недолго, хех

Подождите, на что? Зачем у Вас, кстати, выбирается ctid в запросе?

Подождите, на что? Зачем у Вас, кстати, выбирается ctid в запросе?

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

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

Может, не стоит? Это "внутренняя" штука, и делать так, по идее, ненадёжно.

Я просто не нашел в свое время как сделать лимит в апдейте

Я просто не нашел в свое время как сделать лимит в апдейте

А причём тут LIMIT? Вы лучше значения первичного ключа выбирайте, тогда уж. CTID может измениться, если Вы сразу не блокируете запись (или не работаете на SERIALIZABLE (или хотя бы RR, не помню)).

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

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

Странно... ну ладно. А какая версия PostgreSQL?

10.3

А под условие по startAt много записей попадает? Сколько всего в таблице, кстати?

А под условие по startAt много записей попадает? Сколько всего в таблице, кстати?

И по status..

Всего - около 1.5 миллионов

По startAt когда как, иногда 0, иногда - все, иногда половина от status = 0

По status = 0 - от 0 до 100000 в один момент

По startAt когда как, иногда 0, иногда - все, иногда половина от status = 0

Да, как-то это непросто... а разных priority у Вас сколько?

И да, запрос (или подобные запросЫ) всегда делается со "status = 0" (именно этой константой)?

Этот - всегда

Именно с 0

Разных priority - от -1 до 20, обычное состояние - либо много записей с 0, либо мало с > 0

Видимо, поэтому он и решил однажды воспользоваться индексом на priority

Потому что иногда получалось урвать очень маленькое количество записей

Именно с 0

Можно тогда частичный индекс попробовать.

Видимо, поэтому он и решил однажды воспользоваться индексом на priority

И неудивительно... В смысле, я б на его месте тоже, может, решил бы. ;) Вообще, мне кажестя, идеального индекса именно для этого запроса (так, как он написан) сделать не получится.

А вообще, каков шанс, что он имея индекс на status, priority внезапно решит соскочить на, например, только priority?

А вообще, каков шанс, что он имея индекс на status, priority внезапно решит соскочить на, например, только priority?

Хмм... по идее, вообще не должен "соскакивать" таким образом (может, я чего не вижу...). И, опять-таки, почему бы не частичный индекс (с WHERE status = 0)? Проблема в том, что он может "соскакивать" на другие...

Хотя... если по startAt Вы ничего не создадите, "соскакивать" планировщику будет уже некуда. :)

Alexey Medov будет жить. Поприветствуем!

Всем привет ! Скажите пожалуйста, какое решение лучше всего использовать для разворачивания PostgreSQL кластера Master - Master ?

Я сейчас рассматриваю BDR

Всем привет ! Скажите пожалуйста, какое решение лучше всего использовать для разворачивания PostgreSQL кластера Master - Master ?

Используйте софт)

Bucardo.

Всем привет ! Скажите пожалуйста, какое решение лучше всего использовать для разворачивания PostgreSQL кластера Master - Master ?

А разве честный Master-Madter не у PostgresPro только?

И второй вопрос. Знает ли кто-нибудь, планируется ли в ближайшее время выпуск PostgreSQL со встроенное нормальной репликацией мастер слейв и мастер - мастер ? Я где то слышал что в 10 версии должен появится Master-Master

А разве честный Master-Madter не у PostgresPro только?

Он там действительно имеется ?

Bucardo.

Спасибо за ваше мнение

Он там действительно имеется ?

В ентерпрайз версии

То есть в open sourse версии его не будет ? В том же Mysql вроде без проблем можно настроить

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

То есть в open sourse версии его не будет ? В том же Mysql вроде без проблем можно настроить

Этого я не знаю. На русском можно тут почитать https://habr.com/company/postgrespro/blog/337180/

Этого я не знаю. На русском можно тут почитать https://habr.com/company/postgrespro/blog/337180/

Спасибо ща почитаю ?

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

Спасибо за пояснение. У меня к сожалению нет опыта в развертывании и эксплуатации master-master систем Postgres'a. Поэтому тяжело определится с тем что выбрать Bucardo или BDR. Думаю надо почитать хорошенько статьи в инете.

…а также поднять и поэкспериментировать.

Всем привет ! Скажите пожалуйста, какое решение лучше всего использовать для разворачивания PostgreSQL кластера Master - Master ?

Зависит от требований.

А разве честный Master-Madter не у PostgresPro только?

А что такое "честный"? ;)

А что такое "честный"? ;)

который не обвешивает :D

И второй вопрос. Знает ли кто-нибудь, планируется ли в ближайшее время выпуск PostgreSQL со встроенное нормальной репликацией мастер слейв и мастер - мастер ? Я где то слышал что в 10 версии должен появится Master-Master

Нет, и не в ближайшее не планируется. ;) 10-ка уже вышла, кстати. :)

Спасибо за пояснение. У меня к сожалению нет опыта в развертывании и эксплуатации master-master систем Postgres'a. Поэтому тяжело определится с тем что выбрать Bucardo или BDR. Думаю надо почитать хорошенько статьи в инете.

Вкратце, везде свои ограничения. Choose your poison. ;)

@AlexeyMihaylov будет жить. Поприветствуем!

@White2demon будет жить. Поприветствуем!

Люди, помогите, пожалуйста. В postgres есть пользователь с паролем. Когда пытаюсь сделать psql db userName , получаю отлуп: psql: FATAL: password authentication failed for user userName Хотя, пароль уже через ALTER USER user_name WITH PASSWORD 'new_password'; менял.

Люди, помогите, пожалуйста. В postgres есть пользователь с паролем. Когда пытаюсь сделать psql db userName , получаю отлуп: psql: FATAL: password authentication failed for user userName Хотя, пароль уже через ALTER USER user_name WITH PASSWORD 'new_password'; менял.

проверь, что ему разрешено подключение по паролю в pg_hba.conf

Люди, помогите, пожалуйста. В postgres есть пользователь с паролем. Когда пытаюсь сделать psql db userName , получаю отлуп: psql: FATAL: password authentication failed for user userName Хотя, пароль уже через ALTER USER user_name WITH PASSWORD 'new_password'; менял.

а если дописать --password ?

проверь, что ему разрешено подключение по паролю в pg_hba.conf

local all postgres peer # TYPE DATABASE USER ADDRESS METHOD # "local" is for Unix domain socket connections only local all all md5 # IPv4 local connections: host all all 127.0.0.1/32 md5 # IPv6 local connections: host all all ::1/128 md5 # Allow replication connections from localhost, by a user with the # replication privilege. local replication all md5 host replication all 127.0.0.1/32 md5 host replication all ::1/128 md5

а если дописать --password ?

Пароль дальше он спрашивает, просто отклоняет потом как неверный.

Стоп.

Вместо userName ввел username - и прокатило О_о

Странно, ведь пользователь создавался так: sudo -u postgres psql -c "CREATE USER userName WITH PASSWORD 'password';"

А что такое "честный"? ;)

Это значит синхронный)

Спасибо за помощь.

Это значит синхронный)

Это очень туманное определение, если честно. ;)

А что такое "честный"? ;)

Реальный мастер мастер, а не подобие. И чтобы без проблем, которые нужно вручную править при ошибках репликации.

Вкратце, везде свои ограничения. Choose your poison. ;)

А что из всего доступного имеет меньше всего ограничений ?

Реальный мастер мастер, а не подобие. И чтобы без проблем, которые нужно вручную править при ошибках репликации.

Что такое "реальный мастер-мастер"? > И чтобы без проблем, которые нужно вручную править при ошибках репликации. Каких, например, проблем?

А что из всего доступного имеет меньше всего ограничений ?

Они разные, эти ограничения, вот в чём всё дело. Т.е. зависит от того, что Вам нужно.