Плюс subpartition по регионам допустим

Это нормальный дизайн да, просто поле для партцирования - не дата =)

Это нормальный дизайн да, просто поле для партцирования - не дата =)

Не дата конечно

При партиционировании по дате вы будете менять дату?

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

Если поле для партицирования не дата, то что?

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

то что не будет меняться в общем случае

Ок. Если взять айдишники и по ним партицировать. Но поиск же делается не по айдишникам, а тем же датам. Есть ли смысл партицировать если поиск будет осуществляться по всем партициям?

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

она просто не обновится, т.к. сработают check констрейнты

Ок. Если взять айдишники и по ним партицировать. Но поиск же делается не по айдишникам, а тем же датам. Есть ли смысл партицировать если поиск будет осуществляться по всем партициям?

у нас партиционирование по месяцам и запросы как раз в которых фильтрация идёт по датам. И сканирует только нужные партиции

она просто не обновится, т.к. сработают check констрейнты

Не обновится или не перенесется? Она же должна попасть под правило апдейта

Не обновится или не перенесется? Она же должна попасть под правило апдейта

ни то, ни другое. Если у вас чек констрейнт (a>=100 and a<200), а вы делаете update ... set a = 300, то будет error

(это если без триггера)

Аааа

А с триггером тогда как?

Или это уже гуглить? :)

В общем чуть прояснилось. Спасибор

Или это уже гуглить? :)

с триггером вы уже сами закладываете логику. А я традиционно могу порекомендовать посмотреть в сторону pg_pathman : )

Та я вообще на марияДБ сижу. Просто общие принципы мне непонятны, а по марии посоветоваться не с кем

Вот сюда и написал

в мариидб вроде из коробки партиционирование работает без триггеров

Ну, работать то может, но вопрос с апдейтом остается пока что )

Поэкспериментирую на днях. Отпишусь, если что.

По поводу дизайна и почему так лучше не делать. (Обновлять ключи партиционирования). При данной операции вы физически перемещаете запись между таблицами. Вместо того, чтобы обновлять страницу или блок, вы удаляете в одном месте и вставляете в другом. Получаем дефрагментацию в старой партиции (дополнительная работа для автовакуума) - раз, и дополнительный ввод/вывод на вторую партицию. Таким образом такой дизайн ЗНАЧИТЕЛЬНО увеличивает нагрузку на запись.

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

Спасибо за описание проблемы

Не за что. Даже в оракле (не в суе будет помянут), где с партициями всё очень круто и продвинуто (не даром эта опция стоит как самолёт), даже там по дефолту этого делать нельзя. А в документации английским по белому написано, что включая возможность апдейтить ключи партиционирования вы делаете это на свой страх и риск.

Кто-нибудь, связанный с pg_pathman, подскажите, пожалуйста. Вроде в ветке rel_future_expressions должна была появиться возможность определять партицию через пользовательскую функцию. Я посмотрел diff на README.md и не нашёл ничего связанного с этим. В какую сторону копать? Хотя бы ключевые слова какие-нибудь ).

Да, забыл отредактировать документацию

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

CREATE TABLE test.hash_rel (id SERIAL PRIMARY KEY, value INTEGER NOT NULL, value2 numeric NOT NULL); SELECT pathman.create_hash_partitions('test.hash_rel', 'value * value2', 3); SELECT * FROM test.hash_rel WHERE (value * value2) = 10; , как пример

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

Спасибо большое! Буду тестировать, очень ждал! ??

Спасибо большое! Буду тестировать, очень ждал! ??

Могут быть ошибки, пишите если что сразу в issues на гитхабе :)

Обязательно.

Доброго времени суток , если будет на одном сервере ubuntu ,а на другом CentOS но версии постгреса будут одинаковыми повлияет ОС как-нибудь на производительность потоковой репликации?

по идее нет

Ascandar спасибо

Там ось можен регулировать максимальное количество одновременно активных сетевых соединений всего/на процесс и максимальное количество открытых дескрипторов файлов на процесс/поток. Вцелом к репликации это имеет косвенное отношение.

Да, забыл отредактировать документацию

В доке будет про pg_pathman vs native partitioning in 10? Мне бы хотелось почитать сравнительную характеристику

В доке будет про pg_pathman vs native partitioning in 10? Мне бы хотелось почитать сравнительную характеристику

будет

будет

Круто. Спасибо. Пнёте по готовности?

Коллеги, поговорите со мной вот по такой задачке https://ru.stackoverflow.com/questions/655152/%D0%A1%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0-%D0%BF%D0%BE-%D0%B0%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D1%83-%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%B0-%D0%BC%D0%B0%D1%81%D1%81%D0%B8%D0%B2%D0%B0-%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BE%D0%B2-%D0%B2-jsonb

будет

тоже интересует

Круто. Спасибо. Пнёте по готовности?

если не забудем :)

@ildus, я что-то не так понял, наверное. create_hash_partitions создаёт партиции по хешу выражения всё равно. А я хотел бы, чтобы партиция определялась по значению в столбце типа text. Например, у меня есть столбец, который называется shard_key и если в нём значение 01 я хотел бы запихнуть его в партицию table_01 и так далее. Это возможно?

Может, можно свою хеш-функцию как-то определить?

@ildus, я что-то не так понял, наверное. create_hash_partitions создаёт партиции по хешу выражения всё равно. А я хотел бы, чтобы партиция определялась по значению в столбце типа text. Например, у меня есть столбец, который называется shard_key и если в нём значение 01 я хотел бы запихнуть его в партицию table_01 и так далее. Это возможно?

по описанию больше похоже на партицирование по списку

@ildus, я что-то не так понял, наверное. create_hash_partitions создаёт партиции по хешу выражения всё равно. А я хотел бы, чтобы партиция определялась по значению в столбце типа text. Например, у меня есть столбец, который называется shard_key и если в нём значение 01 я хотел бы запихнуть его в партицию table_01 и так далее. Это возможно?

а если значение "blabla", то партиция как будет называться?

а если значение "blabla", то партиция как будет называться?

Я предполагаю, что можно определить функцию get_partition(value text) которая будет как-то так в моём случае выглядеть: begin if value in ('01', '02', '03', ...) then return value; else return 'default'; end;

Я думал, именно это имелось в виду, когда говорилось, что теперь через пользовательскую функцию можно определять партицию.

Тут поведение такое же как и раньше, просто вместо столбца будет какое либо выражение, названия партиций формируюстя автоматически как раньше. Ну можно отдельным callback-ом переименовывать потом если нужно.

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

В принципе, мне не так важно, как партиции называются, мне важно, чтобы все значения с shard_key = '01' лежали в одной партиции, с shard_key = '02' в другой и так далее.

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

3-й параметр это и есть количество партиций в create_hash_partitions

3-й параметр это и есть количество партиций в create_hash_partitions

Это я понял, по попадают строки в партиции по хешу от значения, а не по значению. Это основная проблема для меня.

В принципе, мне не так важно, как партиции называются, мне важно, чтобы все значения с shard_key = '01' лежали в одной партиции, с shard_key = '02' в другой и так далее.

Это пример list-партицирования, которое можно эмулировать через range с единичным интервалом.

мы изначально отказались от идеи пользовательской хеш-функций в пользу стандартных постгресовых по причине их высокой производительности. В принципе, можно проэмулировать поведение, которое вы хотите. Например, сделать range-партицирование по ключу my_hash(my_column) (где my_hash возвращает строку), потом для каждого возможного случая ('01', '02' и т.д.) создать range-партицию, а в запросах использовать where my_hash(my_column) = '01'

Насчёт list идея хорошая. Спасибо за совет, я попробую.

Но вроде там интервалы только для чисел?

в следующем релизе будет для строк тоже

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

Но вроде там интервалы только для чисел?

собственно в той ветке с выражениямя строковые range уже должны работать

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

ERROR: S client not available

Ребят, как в оконной функции работать со значениями после группировки?

select user_id, sum(price) as cnt ... group by user_id

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

Можно. Но сначала надо пройти курс

как внутри оконной функции получить доступ к cnt ?

оО

Можно. Но сначала надо пройти курс

пройти то пройдут, вот зачем та эта бумашка нужна

Смотря где. Через having или через cte. Без алиаса можно заюзать в некоторых местах.

пройти то пройдут, вот зачем та эта бумашка нужна

Если не нужна, то и проходить не нужно

скорее всего тендер наверняка потребовалось)

?

я читаю маны и вижу, что оконные ункции выполняются после группировки и having

вы напишите как вы хотите использовать

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

так то на кофейной гуще гадать не комильфо

расчет статистики

Пример запроса в студию с использованием cnt aka sum

SELECT customer.uid, SUM ( CASE WHEN transact.type IN ('sub', 'min') THEN transact.amount * (-1) ELSE transact.amount END ) AS balance FROM user as customer INNER JOIN actions AS transact ON transact.user_id = customer.id GROUP BY customer.uid HAVING SUM ( CASE WHEN transact.type IN ('sub', 'min') THEN transact.amount * (-1) ELSE transact.amount END ) > 0 ;

выбирается пара uid - balance

нужен 3-й столбец, вычисляющий % jn j,otuj rjkbxtcndf

от общего количества

я убирал группировку и делал 2 оконные функции

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

Ну значит оконная и having > 0, да

если я переношу логику внутрь оконной функции - ругается, что нужно в условие группировки добавлять transact.amount и transact.type

без этого оконна функция с полной логикой работать не будет

Это оно ругается, что надо сгруппировать внутри окна наверное

если я группирую внутри окна - я не могу использовать having для фильтрации нудевых балансов

потому что оконные функции запускаются после having

Можно разделить операции, сначала посчитать каунты, потом отфильтровать лишнее через cte (WITH)

неужели внутри окна нет доступа к полученной ранее выборке balance ?

так же и having