https://www.postgresql.org/docs/9.5/static/functions-json.html Почитал это - не понял какой аналог tags = ANY ("tag1","tag2")

'{"tags1":1, "tags2":2}'::jsonb ? 'tag1'

Граждане

А напомните, где был репозиторий с pgrc

Для анализа индексов, сексканов и прочего?

я с SQL плохо знаком, но подскажите, где почитать про это. Есть в бд колонка sign типа SMALLINT. Я делаю запрос ...where sign = '1', т.е. сравниваю со строкой. А постгрес делает преобразование и возвращает все строки, в которых хранятся 1, но в виде SMALLINT. Вот этот момент мне не совсем ясен, почему постгрес конвертирует типы при сравнении и где прочитать подробнее про это?

Кто же вас учит цифры в строки загонять и сравнивать? Откуда вы такие беретесь вообще?

Паш, в данном случае БД тебе делает услугу, что находит нужное тебе. :) Если хранится как целое, то и отдаваться будет как целое.

Что ты у неё спросил как строку и она тебе вежливо ответила — это спасибо какбе.

Это не строка, а unknown

подскажите в какую сторону копать: запрос - join 2 больших таблиц на мастере Merge Join, 2 Index Scan (work_mem 128MB) на логической реплике Hash Join, Seq Scan, Index Scan (work_mem 800MB) набор индексов одинаковый, делал analyze, reindex если сделать enable_seqscan = off, то на реплике появляется план с мастера

Выровнять work mem?

Кто же вас учит цифры в строки загонять и сравнивать? Откуда вы такие беретесь вообще?

почему бы в образовательных целях не сравнить?

Паш, в данном случае БД тебе делает услугу, что находит нужное тебе. :) Если хранится как целое, то и отдаваться будет как целое.

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

Выровнять work mem?

Почему на большем объёме work mem такое изменение плана происходит?

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

Эт тебе. И не стесняйся ходить в файлы.

Почему на большем объёме work mem такое изменение плана происходит?

например, сортировка происходит в work_mem-е. Если в память не влезает, то приходится делать merge sort на диске, это сильно дороже

Эт тебе. И не стесняйся ходить в файлы.

Спасибо, поищу. надеюсь там есть именно то, на что я ищу ответ. Реляционная теория мне не нужна вся, основы знаю)

подскажите в какую сторону копать: запрос - join 2 больших таблиц на мастере Merge Join, 2 Index Scan (work_mem 128MB) на логической реплике Hash Join, Seq Scan, Index Scan (work_mem 800MB) набор индексов одинаковый, делал analyze, reindex если сделать enable_seqscan = off, то на реплике появляется план с мастера

например, у тебя SSD и зачем-то random_page_cost=4 вместо 1.01

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

От дисков оно не зависит

Оно от random_page_cost зависит

Это я заработался уже, да посмотрю random_page_cost

Как интересно сегодня получилось. Был запрос UPDATE на каждый хит на сайте, решили оптимизировать и убрать этот апдейт в очереди с прослойкой через редис. Убрали. CPU на сервере с постгресом возрос еще больше.

Не совсем то, что я ожидал ?

Тут конечно стоит оговориться, что аплейкейшен стал обслуживать на 40% больше запросов в целом за тот же период времени, но цель то была другая )

Какое интересное замечание

If the table being analyzed has one or more children, ANALYZE will gather statistics twice: once on the rows of the parent table only, and a second time on the rows of the parent table with all of its children. This second set of statistics is needed when planning queries that traverse the entire inheritance tree. The autovacuum daemon, however, will only consider inserts or updates on the parent table itself when deciding whether to trigger an automatic analyze for that table. If that table is rarely inserted into or updated, the inheritance statistics will not be up to date unless you run ANALYZE manually.

почему бы в образовательных целях не сравнить?

Для образовательных целей слишком часто всплывает этот момент...

можно ли как-то при стриминг-репликации понять когда на standby пришла запись? что-то некоторые с задержкой попадают

можно ли как-то при стриминг-репликации понять когда на standby пришла запись? что-то некоторые с задержкой попадают

мне как-то для целей тестирования нужно было что-то подобное. Я тогда нашел такое решение: SELECT pg_current_xlog_location() <= replay_location FROM pg_stat_replication WHERE application_name = <имя реплики>; и гонял этот запрос до тех пор, пока не станет true. Но у меня был тестовый стенд, не знаю насколько это применимо в реальной работе

мне как-то для целей тестирования нужно было что-то подобное. Я тогда нашел такое решение: SELECT pg_current_xlog_location() <= replay_location FROM pg_stat_replication WHERE application_name = <имя реплики>; и гонял этот запрос до тех пор, пока не станет true. Но у меня был тестовый стенд, не знаю насколько это применимо в реальной работе

спасибо. попробую

а нет. это не то. мне timestamp но скорее всего такого не бывает

сомневаюсь, что где-то хранится timestamp

а нет. это не то. мне timestamp но скорее всего такого не бывает

pg_last_xact_replay_timestamp() ?

pg_last_xact_replay_timestamp() ?

мне интересна конкретная запись

SELECT CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())::INTEGER END AS replication_lag;

select pg_xlog_location_diff(sent_location, replay_location) from pg_stat_replication)/1024/1024

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

sorry

:)

Оно от random_page_cost зависит

сегодня поменял настройки, теперь план совпадает, спасибо

Всем привет. Нужен гуру в PostgreSQL который поможет найти причину деградации в производительности. Разумеется, на возмездной основе. Есть следующий запрос: джойним таблицу А с таблицей Б, сортируем в обратном порядке по столбцу из таблицы А и Б, и делаем лимит 20. В результате джойна получается таблица 35000 записей, но суммарно запрос выполняется около 10 секунд. Индексы есть, вакум делал, но всё равно не могу понять почему так долго выполняется запрос, причем вчера всё работало нормально. Нужна консультация по скайп + покажу всё через тимвьювер.

план запроса в первую очередь смотри

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

explain analyze пробел запрос в https://explain.depesz.com/

и сюда в чатик, будешь наглядным пособием :)

А если сортировать в прямом порядке, всё равно тормозит?

Если нет, то интекс нужен ORDER BY ... DESC

потом окажется, что там select pg_sleep(0.1) from (...)

https://explain.depesz.com/s/oExM

chats - таблица с чатами. messages - сообщения, у каждого есть chat_id. а у чата есть last_msg_id - ссылка на последнее сообщение. получается циклическая зависимость

explain, видимо, анонимизировал запрос )

а, это я сделал)

во - https://explain.depesz.com/s/q9dt

Я уж подумал, наконец-то они додумали до этого (

Я уж подумал, наконец-то они додумали до этого (

там анонимизация всегда была

По unread и date_created есть индексы? Если убрать обратную сортировку из запроса, план изменится?

там анонимизация всегда была

круто

уже делал индексы в обратную сторону CREATE INDEX chat_unread_idx ON chats USING btree (unread DESC NULLS LAST) CREATE INDEX message_date_created_idx ON messages USING btree (date_created DESC NULLS LAST

ERROR: S client not available

Hash Cond: ((messages.y_id)::text = (chats.last_msg_id)::text) вот это странно

ключи - md5 хэши

строки

индекс типа hash пробовали?

нет. на chats.last_msg_id?

По unread и date_created есть индексы? Если убрать обратную сортировку из запроса, план изменится?

вроде не сильно изменилось, всё равно медленно: https://explain.depesz.com/s/5af1

Hash Cond: ((messages.y_id)::text = (chats.last_msg_id)::text) вот это странно

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

А если сделать индексы по column::text? )

Было бы хорошо ограничить выборку до JOIN'а, конечно.

Можно ещё на сам запрос посмотреть?

explain analyze SELECT chats.y_id AS chats_y_id, chats.unread AS chats_unread FROM chats JOIN messages ON messages.y_id = chats.last_msg_id ORDER BY chats.unread DESC, messages.date_created DESC LIMIT 20; это запрос, которые делается для админа, чтобы он мог посмотреть чаты всех пользователей системы. у каждого пользователя будет ещё where

Если я правильно интерпретирую "rows=106453 width=33) (actual time=0.009..5657.857" почти 6 секунд на чтение 500Kb ?

Даже 350 Kb

Нет ли чего странного в системе?

в смысле на сервере? хз, у нас выделенный инстанс под базу - 1 кора, 2 гб оперативки, 5 гб ssd. текущая загрузка - CPU 22%, память 1 гб, жесткий 2.5 гб.

после ребута запрос кстати пошустрее проходит, а потом опять также

в смысле на сервере? хз, у нас выделенный инстанс под базу - 1 кора, 2 гб оперативки, 5 гб ssd. текущая загрузка - CPU 22%, память 1 гб, жесткий 2.5 гб.

work_mem сколько?

work_mem сколько?

4мб ?

подними в метров 200 хотя бы

а там в реальном кейсе нет чего-то вроде user_id in ... ?

не, там ещё хлеще

есть индекс по messages.y_id?

он праймари кий

подними в метров 200 хотя бы

что-то не помогло. правда я не ребутил, но show work_mem показывает новое значение

analyse messages; analyse chats;

давай полный запрос

и set random_page_cost = 1.01

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

и set random_page_cost = 1.01

а почему не 1.00 ?

а почему не 1.00 ?

потому что всё-таки секскан лучше делать не по индексам :)

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

давай с другой стороны set enable_hashjoin to off; и пошарь план