>>но вот если поискать по account который в таблице есть, то запрос начинает работать за приемлемое время Вы же понимаете, что это частный случай?

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

select * from (select account, min(period_code) as period_code from model_oku group by account) tmp order by 2 limit 1

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

потому что можно заставить планировщик отсекать по аккаунту, но что вы будете делать с оверхедом по мере роста таблицы?

а так - обойдетесь индекс ОНЛИ сканом

select * from (select account, min(period_code) as period_code from model_oku group by account) tmp order by 2 limit 1

https://pastebin.com/DJbR65BJ

ну вот, 4-кратная разница выполнения

создайте индекс по аакаунту и период_коду

создайте индекс по аакаунту и период_коду

https://pastebin.com/N7RYkSyy

оставил пока так select period_code from (select distinct period_code from model_oku where account='1000001') _ order by 1 desc limit 1; Execution time: 0.172 ms

все равно чет не понятно

почему поиск по индексу такой медленный?

я сгенерил тестовую таблицу

индекс

30млн записей

примерно с таким же соотношением - 1000 периодов на один аккаунт

'Planning time: 0.184 ms' 'Execution time: 0.062 ms'

у меня другое соотношение. 11 периодов и 12 тысяч account

диск 677.24 MB/sec

на чтение

размер индекса на period_code 458 MB, на account 605 MB, на period + account 196 MB

у меня другое соотношение. 11 периодов и 12 тысяч account

Я посмотрел немного (извините, работаю ;) ). Мне пока непонятна только вот эта оценка: Index Scan Backward using model_oku_period_code_idx on model_oku (cost=0.43..903481.92 rows=2180 width=4) В остальном тут всё, с виду, логично.

https://pastebin.com/N7RYkSyy

(Пролистывая backlog) Вы не тот индекс создали. ;) Ну да ладно, к Вашему вопросу это не относится. Смотрите, дело тут вот в чём: Планировщик предполагает, что всего в таблице 2180 rows, для которых: (period_code IS NOT NULL) AND account = '1040349-Г1' (Предполагает, видимо, исходя из показанного Вами ранее кол-ва разных account; и null_frac для period_code, которую Вы не показывали, т.к. мы и не спрашивали ;) ). А далее проявляется "оптимизм" планировщика (на самом деле, предположение о равномерном, независимом распределении): Раз "Index Scan Backward" стоит 903481.92 и вернёт 2180 rows, то возврат 1 row в 2180 раз дешевле (см. стоимость LIMIT). Но работает это только тогда, когда при "движении вдоль по индексу model_oku_period_code_idx" account = '1040349-Г1' действительно скорее всего встретится после сканирования 1/2180, что верно только в том случае, если account независимо распределены в порядке следования (записей индекса) period_code... что в реальности явно не так, и получается Ups!.

Можете почитать вот тут, например, если интересно: https://www.postgresql.org/message-id/541A2335.3060100@agliodbs.com

Спасибо большое

ктонить пользовался https://pgtune.leopard.in.ua/

как расчитать оптимальные настройки для сервера? озу 132гб cpu 56 версия 9.5

Я предпочитаю вот такой вот конфигуратор: http://pgconfigurator.cybertec.at/

как расчитать оптимальные настройки для сервера? озу 132гб cpu 56 версия 9.5

Почему не 9.6? Он же умеет раскидывать работу по выборке на несколько ядер.

стоит перейти на 9.6?

Я предпочитаю вот такой вот конфигуратор: http://pgconfigurator.cybertec.at/

О, а он, кажется, стал даже получше... Кажется, там раньше не было: "How big is your database (in Gb)?"... или мне кажется?

стоит перейти на 9.6?

Стоит перейти на 10, если есть возможность.

Я предпочитаю вот такой вот конфигуратор: http://pgconfigurator.cybertec.at/

блин там версия только 10)

О, а он, кажется, стал даже получше... Кажется, там раньше не было: "How big is your database (in Gb)?"... или мне кажется?

Это зависит от того, как давно вы на него смотрели. Для меня, например, размер базы всегда присутствовал.

как расчитать оптимальные настройки для сервера? озу 132гб cpu 56 версия 9.5

Слишком мало информации. Даже всего того, что у Вас спрашивают эти конфигураторы, иногда совсем недостаточно даже для правильных приближений. :(

блин там версия только 10)

Ну вот и обновляйтесь.

блин там версия только 10)

Да, уже вот вот 11 выйдет, а там всего лишь 10 ?

Это зависит от того, как давно вы на него смотрели. Для меня, например, размер базы всегда присутствовал.

Наверное, я с чем-то перепутал. Кстати, этот коварно не показывает random_page_cost. ;)

Стоит перейти на 10, если есть возможность.

надо теперь привести веские аргументы для руководства

Ярослав, вот честно, новичку имеет смысл random_page_cost, впрочем, как и все остальные косты крутить? ;) Я вот чегой-то думаю, что не стоит.

надо теперь привести веские аргументы для руководства

На чём вы собрались веЗти аргументы? И что это за аргументы, которые надо возить?

Может всё-таки привеСти?

На чём вы собрались веЗти аргументы? И что это за аргументы, которые надо возить?

спасибо за коррекцию)

спасибо за коррекцию)

Ну и аргументы таки веСкие, а не веЗкие. :)

Ну и аргументы таки веСкие, а не веЗкие. :)

двойное спасибо

Ф

Ярослав, вот честно, новичку имеет смысл random_page_cost, впрочем, как и все остальные косты крутить? ;) Я вот чегой-то думаю, что не стоит.

Эээ... а причём тут новичок или нет? ;) Это для сервера PostgreSQL имеет смысл. Если их криво настроить, оценки вообще перестанут коррелировать с реальной стоимостью, что, я бы сказал, достаточно грустно.

При том, что все сразу понять и осознать, только поставив ПГ, невозможно в принципе. Когда ты знаешь о костах, тебе не нужен конфигуратор. Когда тебе нужен конфигуратор, лезть в косты не имеет смысла, потому что ты тупо не понимаешь, что это такое, и к чему приведёт кручение обсуждаемой группой параметров.

Блин, и эти checkpoint_completion_target крутЮт, ироды!

Я бы ещё из конфигуратора блок Background writer выкинул.

надо теперь привести веские аргументы для руководства

Например, читаете release notes, находите то, что впечатляет. ;)

Например, читаете release notes, находите то, что впечатляет. ;)

https://habr.com/post/339568/ уже отлично!

"Теперь вы можете из коробки делать репликацию отдельных таблиц на другие базы." а как это работает если таблица связана с foreign key? надо их тоже реплицировать?

При том, что все сразу понять и осознать, только поставив ПГ, невозможно в принципе. Когда ты знаешь о костах, тебе не нужен конфигуратор. Когда тебе нужен конфигуратор, лезть в косты не имеет смысла, потому что ты тупо не понимаешь, что это такое, и к чему приведёт кручение обсуждаемой группой параметров.

Так а зачем новичку этим заниматься, если это хоть какой-то "серъёзный" сервер? Для примера, можно купить сервер за 10000$, и "новичок" настроит его так, как бы работал нормально настроенный сервер за 2000$. Не стоит ли как-то иначе подойти к вопросу конфигурирования (обратиться там куда-нибудь, например)? ;)

Так а зачем новичку этим заниматься, если это хоть какой-то "серъёзный" сервер? Для примера, можно купить сервер за 10000$, и "новичок" настроит его так, как бы работал нормально настроенный сервер за 2000$. Не стоит ли как-то иначе подойти к вопросу конфигурирования (обратиться там куда-нибудь, например)? ;)

хотелось бы узнать стоимость консультаций и аудита

(надеюсь это не запрещено правилами чата)

хотелось бы узнать стоимость консультаций и аудита

https://dataegret.ru/

https://dataegret.ru/

сегодня утром написали им запрос)

но пока что на обучение.

Ну вот, ждите ответа. Попутно читайте документацию и пытайтесь что-нибудь сделать сами.

хотелось бы узнать стоимость консультаций и аудита

Ну так обратитесь к кому-нибудь из тех, кто занимается этим (может быть, они к Вам сейчас и лично обратятся, многие из них тут нередко бывают ;) )...

Ну вот, ждите ответа. Попутно читайте документацию и пытайтесь что-нибудь сделать сами.

делаем. сейчас начали переход на 10ку.

делаем. сейчас начали переход на 10ку.

Отпишитесь потом, как прошло. Интересно, однако.

Отпишитесь потом, как прошло. Интересно, однако.

гуглю такой опыт. и везде с 9.6->10 и такое ощущение что нужно с 9.5 - 9.6 - 10

гуглю такой опыт. и везде с 9.6->10 и такое ощущение что нужно с 9.5 - 9.6 - 10

Необязательно. Но лучше, естественно, потренироваться на кошках.

Необязательно. Но лучше, естественно, потренироваться на кошках.

да, есть для этого тренировочный стенд

гуглю такой опыт. и везде с 9.6->10 и такое ощущение что нужно с 9.5 - 9.6 - 10

Нет, не нужно. Почему Вы так решили?

Нет, не нужно. Почему Вы так решили?

просто я ниразу этим не занимался. максимум что делал - установка postgre через докер

"я не трус, но я боюсь"

"я не трус, но я боюсь"

Ну так у Вас же есть стенд, пробуйте. :) Не забудьте, что в каждой major version есть (ну или могут быть) backward-incompatible changes, т.е. Ваши приложения могут (частично) перестать работать. См. release notes, опять-таки.

Ну так у Вас же есть стенд, пробуйте. :) Не забудьте, что в каждой major version есть (ну или могут быть) backward-incompatible changes, т.е. Ваши приложения могут (частично) перестать работать. См. release notes, опять-таки.

не думаю что мы используем что-то специфическое. обычные запросы которые генерит ORM и не замысловатые sql-ки

'Planning time: 0.184 ms' 'Execution time: 0.062 ms'

сколько индексов на таблице, сколько ждойнов?

сколько индексов на таблице, сколько ждойнов?

столько же, как и у автора

джойнов нету