Это да... я, кстати, читал по диагонали threads (в -hackers), связанные с разработкой partitioning в v11, и у меня сложилось впечатление, что как-то там всё с первого раза не очень гладко получилось. :( Потом стали исправлять, естественно, но чем кончилось, не знаю — не следил.

Да, я тоже помню что-то было про partition pruning и что-то ещё

Но вроде все будет ок:)

Ну и много не очень критичных было

можно как-то высчитать место, которое освободится после VACUUM FULL?

посмотреть долю bloat’а по таблице, это даст прикидки сколько данных высвободится

+ еще индексы перестроятся без дыр, тоже место можно прикинуть

касательно секционирования - лучшее, что нам светит в 11 - это импортчасти функционала от pg_pathman щт PgPro

так что если есть желание реально юзать таблицы размером > 1Tb - альтерантив этому расширению нету

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

можно как-то высчитать место, которое освободится после VACUUM FULL?

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

ванильный инхерайтенс в 10ке + пранинг в бетке 11 пока очень сильно сливают

ванильный инхерайтенс в 10ке + пранинг в бетке 11 пока очень сильно сливают

А вы тестировали 11beta2 против pg_pathman, или где-то видели benchmark? Или это всё теоретически?

ну это вы сильно обобщили : )

так что если есть желание реально юзать таблицы размером > 1Tb - альтерантив этому расширению нету

Альтернатива называется "индексы". Более того, в некоторых ситуациях партиционирование им совсем не альтернатива (но на огромных таблицах скорее всего придётся "плакать, колоться" и т.д.). :(

А вы тестировали 11beta2 против pg_pathman, или где-то видели benchmark? Или это всё теоретически?

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

чтобы понять, да или нет

не могу ничего сказать плохого об этом расширении

НО

мы стремимся уходить от всех левых экстеншенов

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

а там нету ни пасмена, ни пг_крона, на которые у нас очень много логики завязано

Альтернатива называется "индексы". Более того, в некоторых ситуациях партиционирование им совсем не альтернатива (но на огромных таблицах скорее всего придётся "плакать, колоться" и т.д.). :(

все опять же зависит от поставленных задач

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

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

ну и создавать кстати тоже)

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

Зачем мне индекс по условию, вообще? Мне хватит и одного. ;) Проблема в его создании и/или обслуживании на огромных таблицах. :(

ну Вы же понимаете, что индекс по одному полю на таких таблицах бесполезен?

вот есть у меня сейчас в проде таблица 20Тб

все опять же зависит от поставленных задач

От запросов/структуры всё зависит, да. К некоторым задачам partitioning (как он есть сейчас) вообще не подходит.

там пару индексов еще под 10 тб выжирают

итого 30Тб мастер + 2 х30 два синхронных слейва + 30Тб асинхронный

итого 120Тб )

без партишинга мы бы умерли это все держать на SSD

а так спокойно старые партиции уводим на другое табличное пространство, отрубаем индексы ненужные

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

ну Вы же понимаете, что индекс по одному полю на таких таблицах бесполезен?

Нет, не понимаю. Потому что это опять-таки зависит от запросов. ;) (Хотя, на практике, чаще всего он, эээ... сильно неудобен).

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

)))

в целом, конечно, все работает, но нужно уходить в GP

точнее уводить старые хвосты

без партишинга мы бы умерли это все держать на SSD

С частичными индексами так тоже можно "танцевать"... но только отчасти. И, опять-таки, временем их построения становится как-то нелегко пренебречь. ;(

мы написали функцию свою для создания индекса

она проверяет, есть ли у таблицы партиции

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

если нету - пихает стейтмент на создание индекса в служебную таблицу

туда раз в минуту ходит pg_cron

и смотрит - если для него задания

если есть - ранит через concurrently

вполне работе в несколько потоков

ERROR: S client not available

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

для разных таблиц - без проблем

т.к. у нас много секционированных таблиц - то все уже испытано боем на кровавом продакшене)

т.к. у нас много секционированных таблиц - то все уже испытано боем на кровавом продакшене)

Так оно и должно работать... я о том, что время построения любого индекса по непартиционированной таблице по сравнению с построением его (по одной секции) с теми же данными в, например, 60 секциях... очень даже отличается.

это да

посекционно в раза два быстрее

юзер - это роль со свойством canlogin

да

utf-8?

Бесспорно utf-8

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

https://www.postgresql.org/docs/current/static/manage-ag-tablespaces.html

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

одна база на одном разделе, другая на другом, или таблицы по разным дискам разнести, одна на hdd, другая на ssd

или индексы

create tablespace fast location ‘/mount/path/to/ssd’

и далее create table veryFastTable(id int) tablespace fast;

типо того )

А вы из какой СУБД к нам пришли? ;)

лучше при создании чем потом )

Тогда это типа data files / filegroups.

хм, sqlite может? ))

Друзья знаю что задача странная, но пока нормализую данные уйдет время а нужно на данный момент решить задачу. Есть таблица где имеется 3 столбца. В первом столбце записаны названия полей из другой таблицы . Как использовать данные чтобы сгенерировать динамически sql ? В list_prices много данных для примера привел только одну. P.S Архитектор не я :) http://sqlfiddle.com/#!15/0ab59/1

+1 ;)