Привет ! Есть какие-нибудь идеи ? https://pastebin.com/5CpDsmgi https://explain.depesz.com/s/TRTX на тестовом выполняется очень быстро Execution time: 536.399 ms , на продакшн сервере нету доступа приходится в слепую.

@netneladno а не имел ли ты дело с merge partitions?

@netneladno а не имел ли ты дело с merge partitions?

не понимаю

Привет ! Есть какие-нибудь идеи ? https://pastebin.com/5CpDsmgi https://explain.depesz.com/s/TRTX на тестовом выполняется очень быстро Execution time: 536.399 ms , на продакшн сервере нету доступа приходится в слепую.

а что будет если выключить netsted loop

объединить две партиции в одну

а что будет если выключить netsted loop

всмысле без последнего селекта ?

объединить две партиции в одну

это будет чтото среднее между дублированием всей таблички и пенальти с кучей табличек

всмысле без последнего селекта ?

set enable nested_loop = off; но вообще проблема в эстимации результата 10к vs 1.5kk

немножно в сто раз ошиблись

вариант оптимизации ?

это будет чтото среднее между дублированием всей таблички и пенальти с кучей табличек

возможно что-то есть интересное в pg_pathman

вариант оптимизации ?

я немного туплю в FROM ((xource.application app JOIN compliance_client cc ON ((app.id = cc.application_id))) JOIN x_compliance_client_license xccl ON ((cc.id = xccl.compliance_client_id))) но кажется что тут порядок джойна руками забит

с set enable_nestloop = off; намного медленнее

set enable nested_loop = off; но вообще проблема в эстимации результата 10к vs 1.5kk

прошу прощенья, эстимейт ок

но мы читали 132кк блоков (по 8кб) на 10к строк

у тебя там в апликейшон блоат что ли

у тебя там в апликейшон блоат что ли

нету там блоата

ничего не понимаю

0.011 мс на лукап индекса в app всего 130мс на весь джойн но внезапно 132кк блоков и 20 минут

я туповат

напиши в перфоманс, хочу знать ответ

так это, можно в том фром раскрыть скобочки?

Привет! Начал новый проект для упрощения действий DBA, пока включает базовые вещи https://github.com/NikolayS/PostgresDBA Присылайте фидбэк, буду рад выслушать идеи (лучше в личку, тут что-то слишком высокая активность!)

прошу прощения за активность вызванную решением некоторой проблемы :)

да не, я про вообще. этот чат сверхактивен уже очень давно

Привет! Начал новый проект для упрощения действий DBA, пока включает базовые вещи https://github.com/NikolayS/PostgresDBA Присылайте фидбэк, буду рад выслушать идеи (лучше в личку, тут что-то слишком высокая активность!)

из всего удобства только криптоалиасы скриптов что ли

хороший вопрос. на самом деле не совсем. С одной стороны да — пока всё очень простое. но ведь и этого не было раньше, всё разбросано по разным местам. во-первых часть скриптов нигде (ну, кроме моего github gist) не публиковалась. Например, генерация do/undo-миграций для прибивания ненужных индексов во-вторых, я постепенно перерабатываю всем известные популярные скрипты (которые если чесно я за много лет уже задолбался копипастить, не знаю как вы) и делаю их более удобными — посмотрите на 2, b1, b2, они сильно модифицированы и стали, на мой взгляд, более удобными. ну и постепенно будут добавляться новые штуки — только что добавил запуск по :dba, появились "узкий" (по умолчанию, только самое главное, зато удобно на ноутбуке смотреть, умещается) и "широкий" режимы. Ну и наконец, штука расширяемая — свои скрипты туда легко положить, перегенерить менюшку init/generate.sh и пользоваться по :dba.

Можно сделать меню цветным и добавить туда ASCII-графики

Вот например банальное, размеры таблиц. Простые вещи — показать Total (сколько строк в вашей БД всего, в сумме по таблицам? а сколько сего индексы занимают?), доли каждой таблиц, индексных частей и TOAST, в процентах. Простая вещь, место много не заняла, но нигде не встречал. В общем-то, вот такие развития благодаря фидбэку получаются, когда разные мнения звучат.

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

ну то есть меню да, можно, я даже там чуток добавил цвета, но вот сами отчёты нет

Вот например банальное, размеры таблиц. Простые вещи — показать Total (сколько строк в вашей БД всего, в сумме по таблицам? а сколько сего индексы занимают?), доли каждой таблиц, индексных частей и TOAST, в процентах. Простая вещь, место много не заняла, но нигде не встречал. В общем-то, вот такие развития благодаря фидбэку получаются, когда разные мнения звучат.

вот например документации нет

с графиками да, можно сильно извращаться (вот для особых любителей экзотики http://akorotkov.github.io/blog/2016/06/09/psql-graph/), но пока цель базовые вещи сделать

>посмотрите на 2, b1, b2 молодой человек!

принятно, согласен что нет, планирую, но сначала форматы отчётов устаканить хочу

Черт, я думал, что толсто пошутил, ан нет...

Объективно - весь интерактив убрать (если только он не на curses написан), только in/out/err и параметры :)

и как это использовать? помнить имена файлов или что?

Ага

ну никто не мешает

не запускайте :dba и даже не прописывайте его в .psqlrc :))

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

update - это delete и insert

ок, спасибо)

в первом приближении delete и insert. Но есть ещё HOT updates.

так что ответ "скорее всего не пересчитывает" в системной вьюхе pg_stat_user_tables есть показатели, сколько обычных апдейтов случилось, сколько HOT

так что ответ "скорее всего не пересчитывает" в системной вьюхе pg_stat_user_tables есть показатели, сколько обычных апдейтов случилось, сколько HOT

очень интересная информация, благодарю!

скорее всего 40млн новых данных у меня будет накапливаться максимум раз в месяц или даже реже

1. Что-то я не пойму, у вас эти данные вечно хранить нужно? 2. А партиции сделать не решение? Там на каждую партицию свой индекс. Создавайте, удаляйте, как угодно. Правда только 1к партиций можно сделать.

Доброе утро! 1. Да, и последующий поиск по данных, как правило, в равной степени затрагивает как новые, так и старые данные 2. Партиции сделать не решение — это замедляет скорость поиска на два порядка и более в данном случае (при ≈500 партициях); про более подробную асимптотическую оценку было чуть выше

Доброе утро! 1. Да, и последующий поиск по данных, как правило, в равной степени затрагивает как новые, так и старые данные 2. Партиции сделать не решение — это замедляет скорость поиска на два порядка и более в данном случае (при ≈500 партициях); про более подробную асимптотическую оценку было чуть выше

1. Хм. Если у вас уже 1ккк строк, то что будет дальше? Думаю постгрес не переварит 1трлн строк в таблице.

1ккк строк (даже больше) — это "первоначальный" массив данных, накопленный за десяток лет С каждым годом он будет увеличиваться в худшем случае на ≈100-200кк максимум

Планируемый срок действия проекта от текущей даты — не более 10ти лет Поэтому в конечном счёте данные вырастут, быть может, в два раза, или чуть больше

Но то трлн не дойдет :)

Но то трлн не дойдет :)

А ну ладно тогда. Хм, 10 лет. А потом всё переписывать?))

специфика проекта такая :) не переписывать: закроется он

специфика проекта такая :) не переписывать: закроется он

Нефтянка наверное. У них там такие загоны есть.)

что-то вроде) подробнее к сожалению запрещает рассказать nda

что-то вроде) подробнее к сожалению запрещает рассказать nda

Да знаю. Сам делал приборы для скважин. Видимо как раз для них проект.

на текущий момент, кстати, созрело три решения проблемы (одно из которых товарищ @netneladno категорично минусует, а другое (MyRocks) рекомендует)

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

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

А вы партиции каким способом создавали?

да хоть нативные постгреса 10, хоть pg_pathman там индексы на каждую партицию свои. можно общий индекс сделать только на ключ партиции — а оно мне не доступно, т.к. им может выступать только идентификатор очередной пачки данных (в моем случае) при поиске же он в запросе не участвует -> сократить время поиска не поможет

да хоть нативные постгреса 10, хоть pg_pathman там индексы на каждую партицию свои. можно общий индекс сделать только на ключ партиции — а оно мне не доступно, т.к. им может выступать только идентификатор очередной пачки данных (в моем случае) при поиске же он в запросе не участвует -> сократить время поиска не поможет

А в чем тут проблема? При любом в подходе у вас должно быть такое условие в запросе, чтобы сожно было еайти нужную партицию. А потом уже работают индексы для конкрктной партиции.

Мне в любом случае нужно будет пробежаться по всем партициям по определению особенностей моих данных :)

Если у вас много данных и искать нужно по разным условиям, может вам стоит посмотреть в сторону ClickHouse?

Мне в любом случае нужно будет пробежаться по всем партициям по определению особенностей моих данных :)

Тогда вам партиции нужны по сути только для упрощения обслуживания таблиц.

Если у вас много данных и искать нужно по разным условиям, может вам стоит посмотреть в сторону ClickHouse?

Смотрели: это рассматривалось еще до постгреса — не подошло :( Индексов у меня много (≈7, и это мультиколумн), поиск — точный В общем никаких преимуществ он не дал

Тогда вам партиции нужны по сути только для упрощения обслуживания таблиц.

иными словами — смотреть в их сторону для решения данной задачи смысла нет

Такое ощущение что кто то пытается mpp в постгресе реализовать

Есть ещё такой вариант. Посмотрите расширение pmpp - оно позволяет одновременно выполнять запросы на разных базах. Вы можете попробовать размазать данные по нескольким базам и искать одновременно, а потом объединять результыта поиска. Такой map-reduce получается.

Или plproxy

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

Есть ещё такой вариант. Посмотрите расширение pmpp - оно позволяет одновременно выполнять запросы на разных базах. Вы можете попробовать размазать данные по нескольким базам и искать одновременно, а потом объединять результыта поиска. Такой map-reduce получается.

увеличение нагрузки в N раз :(

увеличение нагрузки в N раз :(

Какой нагрузки?

@dezconnect не знаком на первый взгляд с этим, посмотрю, спасибо!

Вместо одного большого сервера у вас будет N маленьких, где запросы будут выполняться параллельно, это будет быстрее.

Какой нагрузки?

серверной; из-за параллельной обработки

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

серверной; из-за параллельной обработки

А как вы себе иначе это представляете ??

Вместо одного большого сервера у вас будет N маленьких, где запросы будут выполняться параллельно, это будет быстрее.

что-то слишком сложно выглядит, никто мне "много маленьких серверов" не выделит :) индексы в память не влезут, они весят 50% от размера самой таблицы (все-таки их 7)

А как вы себе иначе это представляете ??

другая архитектура :)

Тогда страдайте

ну, разумеется, параллельность всегда есть

тут подразумевалось в контексте одного select

Тогда страдайте

верно

что-то слишком сложно выглядит, никто мне "много маленьких серверов" не выделит :) индексы в память не влезут, они весят 50% от размера самой таблицы (все-таки их 7)

Тут подойдут и виртуалки.

другая архитектура :)

Расскажите как вы это видите в контексте структур данных не привязываясь к какой либо БД ?

ох уж эти виртуалки с докерами :)

ох уж эти виртуалки с докерами :)

Вы пробовали?

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

@dezconnect вот так, например или MyRocks

Вы пробовали?

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

Вставка и селект это вроде разные операции ?

@pensnarik извиняюсь, вам известна постановка проблемы?

повтори еще раз пожалуйста

я забыл пока спал ? честно