ЧТо запро сдолжен выдавать? select tp.id, tp.title from topics tp join participants pt on tp.id = pt.topic_id where (pt.user_id = 11 and tp.updated_at > pt.last_read) — это понятно, топики, которые пользователь смотрел, и которые обновились. А вторая часть?

select tp.id, tp.title from topics tp join participants pt on tp.id = pt.topic_id where pt.user_id <> 11 and pt.topic_id not in (select topic_id from participants where user_id = 11)

ЧТо запро сдолжен выдавать? select tp.id, tp.title from topics tp join participants pt on tp.id = pt.topic_id where (pt.user_id = 11 and tp.updated_at > pt.last_read) — это понятно, топики, которые пользователь смотрел, и которые обновились. А вторая часть?

Вторая часть - топики, которые пользователь не просматривал.

А нахера ж ему они ?

Там не JOIN

Нет, всё же JOIN. Оптимизатору в этом отношении не важно, что в запросе написано. Когда есть выборка из t1 и t2, и условие вида t1.col1 operator t2.col2, как, например, здесь: > tp.updated_at > pt.last_read это JOIN.

Я думаю, у тебя даже запрос неверный.

Ну, смотри. Вот, например, у нас есть какие-то темы. Они могут быть новые или нет. Допустим, они новые, но пользователь их не видел ещё. Я ему должен их показать.

Или они могли обновиться.

Да у тебя запрос типа Дай мне все обновлённые топики , которые данный пользователь смотрел, а также ВСЮ ОСТАЛЬНУЮ ХРЕНЬ, ЧТО ТАМ ЕСТЬ. может просто проще выбирать ВСЁ, и там уже сортировать, и так далее?

select tp.id, tp.title from topics tp join participants pt on tp.id = pt.topic_id where pt.user_id <> 11 and pt.topic_id not in (select topic_id from participants where user_id = 11)

Ещё раз, ОЧЕНЬ ВНИМАТЕЛЬНО опиши, ОЧЕНЬ ПОДРОБНО, что возвращает этот запрос.

Наверное, да, ты прав.

Наверное, да, ты прав.

А коли так, нужно СНАЧАЛА написать правильный запрос, а потом уже думать, как быстро он будет работать.

Логика такова. При создании / просмотре темы создаётся связь User - Topic. Для каждого пользователя нужно получать список тем, которые он не читал.

Ну, я предполагал, что всё составил верно. Сейчас ещё буду думать.

ЧТо запро сдолжен выдавать? select tp.id, tp.title from topics tp join participants pt on tp.id = pt.topic_id where (pt.user_id = 11 and tp.updated_at > pt.last_read) — это понятно, топики, которые пользователь смотрел, и которые обновились. А вторая часть?

Ну и тут ДОЛЖЕН БЫТЬ DISTINCT!

select DISTINCT tp.id, tp.title

select DISTINCT tp.id, tp.title

Тут должен быть переписанный запрос с EXISTS. ;)

На слейв сервере проблема с выборками bigint(они по схеме такие). Приходится в запросе приводить к integer, чтобы нормально работало. Что-то сломано в реплике в версии 9.6?

На слейв сервере проблема с выборками bigint(они по схеме такие). Приходится в запросе приводить к integer, чтобы нормально работало. Что-то сломано в реплике в версии 9.6?

Какая именно проблема?

Есть user_id::bigint, но при выборке select user_id... не работает запрос на слейве, возвращает пустую строку или ничего не возвращает. Не использует индексы. Еще что-то не делает. Но только в случае что это подзапрос или из join А вот если явно указать select user_id::integer ... начинает работать как надо. Но дело в: 1. Подзапрос 2. Слейв-сервер 3. Приведение к другому типу Это абсолютно не нормально, т.к. на мастере такие запросы отрабатывают отлично без лишних приведений типов.

сравни планы, возможно битый индекс

если не работает с index scan и работает с seq scan, то точно битая реплика

сравни планы, возможно битый индекс

Сравнивали. Много раз и разные запросы. Абсолютно идентичные

сравнивали между чем и чем?

надо не между мастером и слейвом, а с кастом и без каста

если не работает с index scan и работает с seq scan, то точно битая реплика

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

сравнивали между чем и чем?

мастер-слейв.

надо не между мастером и слейвом, а с кастом и без каста

Ок, сейчас проверим

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

Это _не проблема_, а нормальное поведение.

Это _не проблема_, а нормальное поведение.

Угу, уже знаем )))

возможно, битая не только реплика, но и мастер до первой остановки :)

Покажите планы запросов (и \d таблиц) на реплике с CAST и без.

Это _не проблема_, а нормальное поведение.

почему нормальное поведение когда на реплике сиквенсы убегают? кто их там инкрементит(в моем понимании на реплике их вообще нельзя инкрементить). Как объясняется что это нормальное поведение?

почему нормальное поведение когда на реплике сиквенсы убегают? кто их там инкрементит(в моем понимании на реплике их вообще нельзя инкрементить). Как объясняется что это нормальное поведение?

сиквенсы не под правильным mvcc

их инкрементят на диске сразу намного, а потом из памяти раздают значения

почему нормальное поведение когда на реплике сиквенсы убегают? кто их там инкрементит(в моем понимании на реплике их вообще нельзя инкрементить). Как объясняется что это нормальное поведение?

Recovery. Вкратце, инкременты sequnce пишутся в WAL "блоками", т.е. одна запись WAL _заранее_ для блока значений.

Покажите планы запросов (и \d таблиц) на реплике с CAST и без.

Схема https://pastebin.com/WnfNUQU9 Таблица с помощью pathman разбита уже на 8 частей Да, запросы оказались разными ? С кастом https://pastebin.com/BXMP4m1n Без каста https://pastebin.com/inCK6PS2

У нас postgres Pro, а не ванила

Схема https://pastebin.com/WnfNUQU9 Таблица с помощью pathman разбита уже на 8 частей Да, запросы оказались разными ? С кастом https://pastebin.com/BXMP4m1n Без каста https://pastebin.com/inCK6PS2

А схемы дочерних таблиц (хотя бы одной, если одинаковые)?

https://pastebin.com/w1ZS5DYJ

Одинаковые

Только что ограничение установлено

Из особенностей - расширение groonga для fts

Из особенностей - расширение groonga для fts

А Вас не смущает вот это? ;) PGroonga isn't crash safe. If your PostgreSQL process is crashed while updating, your PGroonga indexes may be broken. If your PGroonga indexes are broken, you need to recreate PGroonga indexes by REINDEX. Т.е. Вы пробовали REINDEX на master (или вообще заставить его использовать тот же план, что и реплика)?

А Вас не смущает вот это? ;) PGroonga isn't crash safe. If your PostgreSQL process is crashed while updating, your PGroonga indexes may be broken. If your PGroonga indexes are broken, you need to recreate PGroonga indexes by REINDEX. Т.е. Вы пробовали REINDEX на master (или вообще заставить его использовать тот же план, что и реплика)?

Да. Вчера закрошились индексы. Вчера пересоздали на мастере их через reindex. И пересоздали слейв.

Сегодня еще 3 раза пересоздали слейв.

До сегодня проблем как бы не было, т.к. до этого все запросы были только на мастер. А вот сейчас решили раскидать еще и на слейв чистые селекты. А оказывается они не работают. То есть секунд 10 работали после создания слейва, пока не заехал wal с изменениями. И вот. Есть проблема с индексом groonga на слейве.

Да. Вчера закрошились индексы. Вчера пересоздали на мастере их через reindex. И пересоздали слейв.

Так запросы с CAST и без возвращают разный результат на master (если у них такие же планы, как на реплике)?

Так запросы с CAST и без возвращают разный результат на master (если у них такие же планы, как на реплике)?

это планы на слейве.

сейчас чекнем мастер

Мастер и слейв одинаковые эксплейныдают при приведении типов и без. То есть поведение одинаковое.

Только получается groonga индекс не работает при реплике. ?

Только получается groonga индекс не работает при реплике. ?

Может он через WAL не пролезает?

Может он через WAL не пролезает?

как проверить?

Мастер и слейв одинаковые эксплейныдают при приведении типов и без. То есть поведение одинаковое.

Т.е. результаты-то с CAST/без на master-е одинаковые? А на slave нет?

Т.е. результаты-то с CAST/без на master-е одинаковые? А на slave нет?

Разные.

Разные.

Где разные? Везде?

Получается такие же как и на слейве

как проверить?

Я бы поднял песочницу. Primary + slave. Затем накатил slave до упора, зашатдаунил primary, потом slave и сравнил файлы индекса

Получается такие же как и на слейве

Значит (судя по документации), индексы на master-е сломаны.

Ну либо в лоб применимость - запромотил slave и смотришь как там индекс поживает.

Где разные? Везде?

без каста на мастере и слейве одинаково. с кастом на мастере и слейве одинаково. каст и без каста на мастере разные. каст и без каста на слейве разные.

без каста на мастере и слейве одинаково. с кастом на мастере и слейве одинаково. каст и без каста на мастере разные. каст и без каста на слейве разные.

Ди, я так и понял. Опять-таки, индексы битые на master-е.

Ди, я так и понял. Опять-таки, индексы битые на master-е.

Им менее суток, они пересозданы.

Им менее суток, они пересозданы.

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

Только получается groonga индекс не работает при реплике. ?

если он "не crash-safe", то он и реплицироваться не будет

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

А вот этого мы не знаем

https://github.com/pgroonga/pgroonga/issues/25

А вот этого мы не знаем

Эээ... что? Если [детерминированный и т.д.] запрос даёт разные результаты в зависимости от плана, значит что-то не так, нет?

Эээ... что? Если [детерминированный и т.д.] запрос даёт разные результаты в зависимости от плана, значит что-то не так, нет?

Так дело в том, что мы так раньше не делали. Сегодня начали пробовать и да - не так. Так не должно быть.

Так дело в том, что мы так раньше не делали. Сегодня начали пробовать и да - не так. Так не должно быть.

Вот именно. Ладно, а Вы все описанные здесь https://pgroonga.github.io/reference/replication.html "шаманские танцы" исполнили? ;)

Вот именно. Ладно, а Вы все описанные здесь https://pgroonga.github.io/reference/replication.html "шаманские танцы" исполнили? ;)

Нет. Сами только-только нашли. Это плохо. ?

Нет. Сами только-только нашли. Это плохо. ?

Но, с виду, это всё не имеет отношения к тому, что индексы у Вас так себя ведут на master-e. Т.е. разберитесь сначала с этим...

Но, с виду, это всё не имеет отношения к тому, что индексы у Вас так себя ведут на master-e. Т.е. разберитесь сначала с этим...

Они ведут себя отлично на мастере. Просто мы выявили что каст с бигинта на инт помогает на слейве. И я ввел вас всех в заблуждение, наверное, этим

Они ведут себя отлично на мастере. Просто мы выявили что каст с бигинта на инт помогает на слейве. И я ввел вас всех в заблуждение, наверное, этим

Подождите, вы только что писали, что результаты _того же самого запроса_, только с CAST-ом, отличаются _на master-е_. Или я не так понял?

Подождите, вы только что писали, что результаты _того же самого запроса_, только с CAST-ом, отличаются _на master-е_. Или я не так понял?

И так и не так. условно есть user::bigint и на слейве с ним не работает индекс, мы ж запросы без каста делаем, как есть, то есть с bigint. но если сменить на user::integer, то начинает давать результат.

но с кастом у вас " -> Index Scan using messages_8_chat_id_message_id_key on messages_8 msg_7 (cost=0.43..8.46 rows=1 width=1006)" " Index Cond: ((chat_id = (last_message.chat_id)::integer) AND (message_id = (last_message.max)::integer))" а без каста " -> Index Scan using messages_8_id_chat_id_message_id_lower_idx on messages_8 msg_7 (cost=0.00..4.01 rows=1 width=1006)" " Index Cond: ((chat_id = last_message.chat_id) AND (message_id = last_message.max))"

индекс messages_8_id_chat_id_message_id_lower_idx битый

каст не нужен по сути. мы выявили что проблема не на мастере. и не с индексом на мастере. мы выявили что слейв норм работает до первых wal логов. то есть беда именно в индексе и только после wal. плюс ссылки - мы не включили groonga индекс мигрировать

last_message.max это бигинт.

а каст в инт

каст не нужен

каст просто срубает план, заходящий в битый индекс, в планировщике

> каст и без каста на мастере разные. > каст и без каста на слейве разные. Вот же Вы пишите... Я там про _результат_ спрашивал, не про планы.

> каст и без каста на мастере разные. > каст и без каста на слейве разные. Вот же Вы пишите... Я там про _результат_ спрашивал, не про планы.

так если без каста и с кастом в бигинт - то идентичные!!!

> каст и без каста на мастере разные. > если без каста и с кастом в бигинт - то идентичные!!! Я один здесь вижу противоречие? ;)

> каст и без каста на мастере разные. > если без каста и с кастом в бигинт - то идентичные!!! Я один здесь вижу противоречие? ;)

каст в инт и без каста - разные. каст в бигинт и без каста - идентичные.

нашли. индекс на слейве 160кб, на мастере несколько гигов

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

подскажите, пожалуйста, как получить результаты, даже если искомое поле NULL, т.е. в условии стоит where filed!=1, и как я заметил, NULL не попадает под это, есть какой-то флаг, что бы не писать where filed!=1 or filed is NULL?

тебе нужны is distinct from и is not distinct from

тебе нужны is distinct from и is not distinct from

понял, спасибо, работает. а флага все-таки нету? что бы код не переписывать

если кто-то написал код, не зная sql, его нужно переписать

если кто-то написал код, не зная sql, его нужно переписать

справедливо

если кто-то написал код, не зная sql, его нужно переписать

Ну, кто-то же сделал transform_null_equals для broken code примерно на ту же тему. ;)