|
|
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
Доброе время суток. Имеем PG 9.2 на Gentoo. Скромные 4 ГБ оперативки, из них в shared_buffers = 1900MB. constrain_exclusion = partition. Есть 2 таблицы, родительские Код: plsql 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. Триггера на них висят такие Код: plsql 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. Все работает, данные пишутся (быстро или нет - вопрос отдельный). SELECT COUNT(1) FROM ONLY indexed_result и SELECT COUNT(1) FROM ONLY indexed_result_ext возвращают нули. Выборка существенно подтормаживает. Причем explain показывает, что партиции используются, однако сканирование родителя все равно идет. Код: plsql 1. 2. 3. 4. Код: 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. Вопрос - зачем выполняется "Seq Scan on public.indexed_result_ext ire (cost=0.00..199794.00 rows=1 width=48)", если партицированные таблицы существуют ив ыборки по ним успешно прошли "Bitmap Heap Scan on part.indexed_result_ext_19 ire (cost=26.03..2336.07 rows=1258 width=48)" за время, в 100 раз меньшее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 15:10 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
kamakama, потому что так устроено и в родительской таблице тоже могут быть строки только вы время неверно смотрите... explain показывает ожидаемое время а не реальное реальное - explain analyze только ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 15:37 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
kamakama... Вопрос - зачем выполняется "Seq Scan on public.indexed_result_ext ire (cost=0.00..199794.00 rows=1 width=48)", если партицированные таблицы существуют ив ыборки по ним успешно прошли "Bitmap Heap Scan on part.indexed_result_ext_19 ire (cost=26.03..2336.07 rows=1258 width=48)" за время, в 100 раз меньшее? Как зачем? Там нашлась как минимум одна строка, удовлетворяющая результату. Это на дочерние таблицы есть четкие ограничения на таблицу, а в родительской может быть все что угодно. То что это "все что угодно" распихивается триггером по дочерним - это частный случай здесь и сейчас, то есть далеко не правило, на которое можно надежно опираться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 15:43 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, Специально для обеих таблиц сделал VACCUM и ANALYZE. После чего сделал рельный запрос. Помогло, статистика была старой. Но эффективность такой организации партицирования вызывает большие сомнения. Возможно, что наследуемые таблицы - это просто притянуто за уши и невозможно конкретно указать, что это - партиция и не нужно шарится в родителе. Тему можно закрывать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 15:50 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
Хотя сейчас по мере работы возник еще один вопрос. Вот есть схема с партициями, и для id родителя указан "id bigint NOT NULL DEFAULT nextval('indexed_result__id_seq'::regclass)". И теперь выполняем insert в родитля, причем хотим, чтоб он вернул id (типа insert into indexed_result ... returning id into id_indexed_result). Но в таблице нет записей и стало быть, вернется null (что и происходит в реальности). Отдельный сиквенс для Id каждой партиции дать нельзя (наследование же), так как же заставить эту конструкцию работать? Или никак и присвоение id руками делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 17:06 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
kamakama, можно в триггере партицирования возвращать new только с id, остальное занулять. тогда в родителе будут жить только айдишки и ретурнинг будет работать. но тогда скорее всего надо будет переделать доступ к партициям, на вариант, когда явно партиция с клиента выбирается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 17:10 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
kamakama, Вы описали основные "бяки" в работе с партиционированием в PostgreSQL. Да, это способ выкрутиться при отсутствии полноценной поддержки. И да, он далек от идеала. Для последовательностей -- да, нужно присваивать ID явно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 17:13 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
kamakama, я когда-то для returning писал ужасный костыль в виде нескольких триггеров. в before insert триггере делалась вставка в партиции и возвращался new. в after insert эта запись удалялась из родительской таблицы. по-другому вроде бы сделать тогда нельзя было. не знаю, изменилось ли сейчас что-то. shared_buffers = 1900MB может быть не совсем оптимальное значение если на сервере только база. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 17:18 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
Понятно, спасибо. Но решать таким образом проблемы - костылеобразно:( Ведь главный козырь партиции - то, что ее можно внедрить прозрачно по отношении к остальному коду, типа клиент этого и не заметит. А тут, если обращение к таблицам не изолировано процедурами, прозрачностью и не пахнет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 17:20 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
Alexius, почему неправильно? Только база. Просто объемы данных у нас таковы, что все активно используемые таблицы и индексы (даже после партиций) влезают в 2,5 ГБ + 400M запас. Объем разделяемой памяти выделели системщики в 3 гига, метров 200 под остальными приложениям ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 17:24 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
Alexiuskamakama, я когда-то для returning писал ужасный костыль в виде нескольких триггеров. в before insert триггере делалась вставка в партиции и возвращался new. в after insert эта запись удалялась из родительской таблицы. по-другому вроде бы сделать тогда нельзя было.да, это работает. можно всю вставку в партиции перенести в after. С соответсвующим DELETE из ONLY корня. тогда returning тоже будет работать. интересный теор вопрос -- пухнет ли предок на незавершённых вставках. [Тут интересен еще случай с мигрирующим UDATE, который превращается delete + INSERT, но не с точки зрения returning, а с т.з. генерации событий для, скажем, триггерной передачи их в другую бд]. -- многовато событий по итогу получается (update -- поскольку в немигрирующем случае передаем его, delete -- поскольку таки удалили, и (re) insert -- поскольку таки вставили. А если мишень партицирована иначе -- то главное не ошибнуться с порядком событий - с ONLY и явным адресом там не очевидно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 17:34 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
kamakamaПонятно, спасибо. Но решать таким образом проблемы - костылеобразно:( Ведь главный козырь партиции - то, что ее можно внедрить прозрачно по отношении к остальному коду, типа клиент этого и не заметит. А тут, если обращение к таблицам не изолировано процедурами, прозрачностью и не пахнет единтвенное что ломается это returning так что не так плохо а запросы на партиционированную таблицу всеравно переделывать зачастую приходится (так как надо явным образом условия выбора партиции добавлять в запрос) PS: осмысленность вашей схемы партиционирования (критерий выделения партиций) - под большим вопросом, т.е. может быть в вашей конкретной ситуации это и правильно но вообще почти всегд партиционирование по чему то кроме даты оказывается лишним. Да и размеры партици какие то неудачные (если в партициях меньше миллиона а лучше 10M строк - они обычно не актуальны). PPS: больше 100 партиций делать не стоит в базе они линейным поиском выбираются PPPS: обращение к пусто родительской таблице - штука почти бесплатная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2014, 22:32 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
kamakamaAlexius, почему неправильно? Только база. Просто объемы данных у нас таковы, что все активно используемые таблицы и индексы (даже после партиций) влезают в 2,5 ГБ + 400M запас. Объем разделяемой памяти выделели системщики в 3 гига, метров 200 под остальными приложениям обычно рекомендуется выставлять shared buffers в ~25%/~75% от размера доступной памяти постгресу (- память на коннекты) чтобы уменьшить эффект от двойного кэширования. раз все, что нужно в 2.5ГБ влезает, может быть стоит поднять размер поближе к этому значению, хотя разницы возможно большой и не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.12.2014, 19:53 |
|
||
|
И снова про партиции - почему сканируется пустая таблица родитель?
|
|||
|---|---|---|---|
|
#18+
Alexius, У нас есть мастер-таблица,которая генерирует ключи, служащие основанием для партиции. Сейчас там 2М записей и ее бить не нужно (пока). Но эти ключи используются в качестве вторичных для других объектов, которых существенно больше (примерно в 10-12 раз). И уже эти таблицы получаются примерно по 1-1.2М строк. Собственно, для ускорения рабты именно с вторичными объектами, а не с первичными и затевалась эта схема. Да, есть минус, что при обращении нужно использовать всегда мастер ключ, но у нас это 95% запросов. А на 5% найдем кастомное решение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2014, 19:15 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38822815&tid=1998310]: |
0ms |
get settings: |
10ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
188ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
2ms |
| others: | 235ms |
| total: | 544ms |

| 0 / 0 |
