|
Обслуживание секций
|
|||
---|---|---|---|
#18+
Есть секционированная таблица ru.propose_sod и её секция private.propose_sod_ru_2019 с данными за 2019г размером 1,8ТБ Планирую заменить период секционирования с "годового" на "помесячный" (слишком медленно выполняются запросы + сложности в обслуживании секций) Можно ли в наполненной секции заменить верхнюю границу диапазона с '2020-01-01' на '2019-11-01'? Не повлечет ли это действие риск потери данных или выделение дополнительного пространства на диске (который и так переполнен) или блокировку таблицы на длительное время... ? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60.
PostgreSQL 11 / Ubuntu / Размер БД 7,2ТБ / Заполненность диска 96%(!) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2019, 14:46 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
SET friday_mode = ON; Сначала хорошо бы сделать VACUUM FULL. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2019, 14:51 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5.
без check attach partition будет проверять данные на соответствие ограничению. (seqscan в один поток без индексов) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2019, 14:55 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
lr2Сначала хорошо бы сделать VACUUM FULL. Это повлечет за собой блокировку и выделение места ~ 1,8ТБ для пересоздания таблицы. А места уже нет :-( ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2019, 15:14 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
Melkij, спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
18.10.2019, 15:46 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
Добрый вечер! Подскажите пожалуйста, а можно где-нибудь в Postgres посмотреть границы уже созданной секции RANGE? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.05.2020, 18:13 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
MacArrow, в DDL секции ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2020, 16:58 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
DSKalugin, Спасибо! Это понятно, особенно теоретически... А есть какие-то таблицы, представления, "хранимки", из которых по запросу можно получить необходимые данные о секции, в том числе и границы диапазона? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2020, 15:07 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
MacArrow А есть какие-то таблицы, представления, "хранимки", из которых по запросу можно получить необходимые данные о секции, в том числе и границы диапазона? Технически это pg_class.relpartbound. Но это pg_node_tree. pg_dump и psql с ним работают просто как с данностью (psql вызывает именно так): SELECT c.oid::pg_catalog.regclass, pg_catalog.pg_get_expr(c.relpartbound, c.oid), c.relkind FROM pg_catalog.pg_class c, pg_catalog.pg_inherits i WHERE c.oid=i.inhrelid AND i.inhparent = '159622' ORDER BY pg_catalog.pg_get_expr(c.relpartbound, c.oid) = 'DEFAULT', c.oid::pg_catalog.regclass::pg_catalog.text; В результате получается всё выражение текстом, например "FOR VALUES FROM ('2020-04-01 00:00:00') TO ('2020-05-01 00:00:00')" ... |
|||
:
Нравится:
Не нравится:
|
|||
15.06.2020, 16:20 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
Melkij, Большое спасибо! А вот ещё вопрос: можно ли по значению ключа секции определить саму секцию (имя)? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.06.2020, 22:24 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
MacArrow, емнип tuple routing из backend'а не экспортирован никак. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.06.2020, 13:36 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
Melkij, Понятно! Спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2020, 15:59 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
Написано: "Создайте в секционируемой таблице индекс, будет автоматически создан отдельный индекс в каждой секции, и все секции, которые вы будете создавать или присоединять позднее, тоже будут содержать такой индекс". Вопрос: Если индекс создан в "голову" уже после создания секций (очень многих секций, причём в разных таблицах разными методами), есть ли "штатная" возможность создать индексы по всем секциям? Или же поможет только самописная процедура, которая всё это сделает? Буду весьма благодарен за конструктивный ответ. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.08.2020, 21:06 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
MacArrow Если индекс создан в "голову" уже после создания секций (очень многих секций, причём в разных таблицах разными методами), есть ли "штатная" возможность создать индексы по всем секциям? create index на головной раздел по всем секциям индексы сам и создаст. А вот если нужен create index concurrently - то только ручками. Оживление сейчас по этому вопросу есть, может в pg14 и войдёт даже. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2020, 12:37 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
Melkij, И снова огромнейшее спасибо! Я имел в виду, что при создании секции, в этой же секции создаются индексы по "головному". Если это concurrently, то да, он. Просто столкнулись с такой проблемой: потребовался новый индекс на секционированную таблицу, создали в "голову", но на быстродействие запроса это никак не повлияло... Ради эксперимента отдетачили и приаттачили секции по одной из таблиц, индексы в секциях создались и запрос выполнился много быстрее. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2020, 11:15 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
MacArrow, уточните как именно индекс создавался. Конкретный запрос. create index on table_name - создаст индексы по всему дереву create index concurrently on table_name - откажется работать, т.к. поддержка пока не реализована create index on only table_name - создаст invalid индекс только на головном разделе и так и задумано. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.08.2020, 13:07 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
Melkij, Я извиняюсь за нубство в этом вопросе, т.к. не вникал особо, как Постгрес сам делает индексы на секции... Но если конкретно, то алгоритм такой: - при создании таблицы, скриптом же создавался индекс по ключевому столбцу, например: скриптикиCREATE TABLE balance (id serial, acc_id bigint, in_amt numeric, dt_amt numeric, ct_amt numeric, out_amt numeric, op_dt date) PARTITION BY RANGE (op_dt); CREATE INDEX balance_op_dt_idx ON balance (op_dt); - дальше, перед загрузкой вызывается АПИ, где создаётся секция (примерно как тут ) и автоматом ПГ создаёт индекс на секцию. Поискав по DDL, нашёл для этих секций связанные скрипты создания индексов, например, вот один из них (получается, что никакого concurrently): скриптикиCREATE INDEX balance_20200701_op_dt_idx ON balance_20200701 USING btree (op_dt); - уже после загрузки данных потребовалось ввести новый индекс на acc_id, который создали в "голову": скриптикиCREATE INDEX balance_acc_id_idx ON balance (acc_id); Но он не возымел никакого действия на быстродействие Как я понял опытным путём, это из-за того, что не были созданы индексы на секциях (выявлено отсутствием DDL-скриптов для индексов, привязанных к этим самым секциям). Дальше Вы мне подсказали, что индексы на секции "штатными" средствами ПГ никак быстро не создать, а только ручками... Как выяснилось теперь, Вы имели в виду что-то другое Тем не менее, самописной процедурой, где отдетачили и снова приаттачили все секции, были всё-таки (полу-)автоматически созданы так необходимые индексы на каждую секцию. В результате получили необходимое быстродействие выполнения запросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 20:50 |
|
Обслуживание секций
|
|||
---|---|---|---|
#18+
Да, забыл... Соответственно, в результате выполнения этой "самописной процедуры detach&attach", появились DDL-скрипты для индексов, привязанных к этим самым секциям, например такой: скриптикиCREATE INDEX balance_20200701_acc_id_idx ON balance_20200701 USING btree (acc_id); P.S. Если что, то эти самые скрипты (да и сами индексы и другие объекты БД) я вижу при помощи DBeaver. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2020, 21:12 |
|
|
start [/forum/topic.php?fid=53&msg=39989325&tid=1994511]: |
0ms |
get settings: |
17ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 16ms |
total: | 166ms |
0 / 0 |