|
|
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
Для начала, пара полезных функций: Код: plaintext 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. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 07:52 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
Посмотрим пример отсюда . postgresql.org For example, suppose we are constructing a database for a large ice cream company. The company measures peak temperatures every day as well as ice cream sales in each region. Conceptually, we want a table like this: Код: plaintext 1. 2. 3. 4. 5. 6. Вручную создавать партиции, индексы и правила - лень. Поэтому создадим их для measurement: Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 08:03 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
А потом напишем функцию, которая создаёт партиции и правила: Код: plaintext 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. 61. 62. 63. 64. 65. 66. 67. 68. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 08:10 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
Теперь, чтобы создать партицию, можно вызвать функцию partition_month: Код: plaintext 1. 2. Можно и триггер: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Тут слабое место - NEW.logdate. Можно написать функцию, составляющую триггер для oid. Или передавать просто - NEW - в функцию, вызывающую в свою очередь partition_month (overloading), или передавать anyelement - и у нас уже полиморфизм. :-) Проверяем триггер: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2007, 08:26 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
В общем, если вдруг кому интересно, попробую изложить дальше мысли по поводу автоматического создания партиций. Вот такое абстрактное время (в секундах) выполнения вставки семи тысяч строк в measurements: Код: plaintext 1. 2. 3. 4. Видно, что в отличие от (свежесозданного) набора правил, триггер просто рулит. :-) Как оно работает: plpgsql: 1. выясняется имя нужной партиции 2. генерируется строка для values (...) 3. execute 'insert...' си: 1. SPI_blah используется для того, чтобы выяснить oid нужной партиции 2. по oid открывается соответствующая реляция, 3. вставляется tuple (heap_insert), 4. генерируются индексы (FormIndexDatum, index_insert) В сишном триггере (он сырой и вообще for fun), собственно, для партиции не проверяются constraint checks, а также не поддерживаются partial и ещё бог знает какие индексы. Причём, тут есть повод задуматься. Например, вообще не строить индексы во время вставки (для доступа к новым данным нужно будет отключать enable_indexscan и enable_bitmapscan), а перестраивать их потом, после вставки огромного количества строк. Переработанные исходники (в том числе и сишного триггера): здесь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2007, 12:32 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
Что то у меня не получилось !! При проверке все данные оказались в одной таблице После удаления данных и повторном Insert все встало на свои места.... Я в вашем исходнике запутался :( Я только начинающий и непонимаю в чем отличие RULE от TRIGGER (вернее я не понимаю что на каком этапе срабатывает) PS Windows XP / PostgreSQL 8.2.3 PPS Все настройки по умолчанию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2007, 16:07 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
Добрый день. Тема более чем актуальна. Решение довольно элегантно и компактно. Для меня лично решение используя С триггер более приемлемо. К сожалению не смог оценить С-триггер, т.к. не работает указанная Вами ссылка. Если есть возможность, выложите еще раз. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2007, 15:34 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
Сегодня что, первое апреля? Это сообщение я уже когда-то видел, опять над новичками издеваетесь. Выкопал свои функции создания разделенных таблиц, см. http://postgrestips.blogspot.com/2007/06/partitial-table.html P.S. Вот после таких шуточек от постгреса шарахаются, как черт от ладана... Идите к мускульщикам, у них все равно база падает постоянно, авось не побьют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2007, 21:37 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
MBGСегодня что, первое апреля? Это сообщение я уже когда-то видел, опять над новичками издеваетесь. Выкопал свои функции создания разделенных таблиц, см. http://postgrestips.blogspot.com/2007/06/partitial-table.html P.S. Вот после таких шуточек от постгреса шарахаются, как черт от ладана... Идите к мускульщикам, у них все равно база падает постоянно, авось не побьют. Угу. Первое апреля. Объясняю: была необходимость создания универсального решения. С чем, собственно, и справился. Здесь хотел поднять тему для обсуждения, но, видимо, неправильно начал - с публикации невнятных исходников. :-) Моя вина. Теперь по поводу статьи, которая по ссылке. Код: plaintext 1. Пытался ли автор автоматизировать "маршрутизацию" данных при вставке оных в родительскую таблицу? Или запрет диапазонов - это решение? "Теперь данные, для которых нет подтаблицы будут игнорироваться с выдачей..." - а не лучше ли тут же и создать такую "подтаблицу"? :-) Мне лично такой вариант симпатичнее. 2. Были ли попытки посчитать время, затраченное на вставку данных при росте набора вот этих вот Код: plaintext 1. Теперь попробую объяснить, чего же я всё-таки добивался. 1. Создания дочерних таблиц (или like-таблиц) с индексами, триггерами, проверками, правилами, и т.д., как у предка. Вроде бы в 8.3 это будет, по крайней мере индексы. 2. "Умной" и беззаботной загрузки большого (или небольшого) объёма данных в родительскую таблицу, при этом не заботясь о ручном создании дочерних. Представим себе (пример с потолка) средненькую такую табличку, допустим, с бухгалтерскими проводками (или с телефонными звонками) средненькой такой фирмы за 3-летний период. Которую вдруг решили "партиционировать" по месяцам. 36 дочерних таблиц - это уже огогоськи. Тут Код: plaintext 1. 2. При этом с "do instead", я уверяю, всё будет грустнее и грустнее. Вообще, конечно, зависит от объёмов и требований. 3. Триггер, который бы разруливал вставку, теоретически должен уметь работать с любыми типами данных (под типом данных я подразумеваю также и таблицы сами по себе). Тут, в общем, вариантов - масса. PS: Пусть я нездоровый велосипедист, ну да ладно. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2007, 22:33 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
Что-то говорили о триггере на Си? Начнем с того, что писать на Си триггер далеко не лучшая идея. А те специалисты, кто может это сделать грамотно, в подобных советах не нуждаются :-) Далее, если есть заморочка с быстродействием (притом, что rule для сотен подтаблиц с разбиением например по месяцам отлично справляется), то необходимо использовать prepared запросы в триггере, иначе все будет еще медленнее. А приведенный вариант кроме большей заморочности пользы не принесет. Цифры быстродействия выглядят странно, на plpgsql такой скорости триггеров я не видел (тестил на PostgreSQL 8.0, сейчас сижу на 8.1, но уже не проверял). Насчет 100 таблиц "не вижу препятствий" foreach table {table1 table2 ... table100} foreach year {06 07} { foreach month {01 02 03 04 05 06 07 08 09 10 11 12} вроде как можно догадаться, верно? А насчет множества таблиц и проч. все делается малость не так. Пишется скрипт создания новой схемы БД "с нуля" (делаем дамп структуры, что нужно, выкидываем и заменяем скриптом) и в новую схему все переливается из старой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.07.2007, 23:37 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
MBGЧто-то говорили о триггере на Си? Начнем с того, что писать на Си триггер далеко не лучшая идея. :-) Мдее. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 08:31 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
glebofff Код: plaintext Кстати, если я ничего не упустил, то функция копирования индексов скопирует также индексы для PK и UNIQUE constraint'ов, то есть мы получим по два одинаковых индекса на каждый PK и UNIQUE. Побороть можно немного изменив выборку индексов на: Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 13:16 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
Thamerlan Кстати, если я ничего не упустил, то функция копирования индексов скопирует также индексы для PK Угу, спасибо. Для меня на тот момент было несмертельно. Двух одинаковых не должно быть, имена-то одинаковые. А так, конечно, надо отделять мух от котлет. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 16:46 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
Спустя минувшие почти десять лет не могу, без сожаления, не констатировать нескольких фактов: 1. в юности я был, конечно, максималист, и связно рассказывать о своих идеях не умел, 2. не умею и сейчас, 3. статей о партиционировании по интернету - хренова туча, но так никто дальше не продвинулся, 4. моим "решением" люди пользуются до сих пор, и, наверное, стоит этот мутный поток переписать заново. Сверху ссылка на триггеры битая, вот, выкладываю https://cloud.mail.ru/public/1ea876e69907/partitioning.tar.bz2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 07:38 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
glebofff, посмотрите в исходники лондайста3, там люди изящно копируют констрайнты и индексы , просто делая в одном предложении как inherit так и like .... including all с предка. кроме того, при инхерит постгрес наследует все прочие констрайнты сам, без ансам а относительно новая опция ...constraint ... no inherit позволяет отделить одно от другого. т.е. я пишу не like ... including all, а всё, без констрайнтов (которые заимствуются инхеритс-ом), а лайк мне бы ещё и no inherits скопировал --такие вещи за 10 лет можно бы было приметить, что ли ну и ещё, по мелочи. но, посмотрел, ф-ии, судя по виду, -- полезные, т.ч. можете гордиццо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2015, 08:40 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
glebofff4. моим "решением" люди пользуются до сих пор, и, наверное, стоит этот мутный поток переписать заново.В сырцах не заметил перенос привилегий GRANT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 13:12 |
|
||
|
Партиционирование (нудно, сплошные сорцы :-)
|
|||
|---|---|---|---|
|
#18+
SmeL_mdglebofff4. моим "решением" люди пользуются до сих пор, и, наверное, стоит этот мутный поток переписать заново.В сырцах не заметил перенос привилегий GRANT. помедитируйте над: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. т.е. фунцикло пишется на коленке за 5 15 минут. а если посмотреть в кишки information_schema. table_privileges -- то можно ещё и много лишнего ручками снести. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2015, 13:54 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38889077&tid=1998145]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
181ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
78ms |
get tp. blocked users: |
2ms |
| others: | 246ms |
| total: | 553ms |

| 0 / 0 |
