|
пятничная задачка
|
|||
---|---|---|---|
#18+
в разборе проблем пж на хабре есть хадачка https://habrahabr.ru/company/devconf/blog/353682/#comment_10763534 авторТам была не очень специфическая задача: раз в день переносить изменения из PostgreSQL в OLAP, для чего в PostgreSQL завели заполняемую триггером таблицу change_log. Нужно было всего-то вычитать из нее данные и почистить ее. Так вот: мне не удалось найти решение, которое бы работало за линейное время и при этом умело вычитывать эту таблицу по частям. Получилось либо удаление всех записей в одной большой транзакции с чтением удаляемых при этом данных, либо квадратичный алгоритм (оптимизатор упрямо сует в план запроса на удаление полный проход по таблице). Итог в любом случае один и тот же: если позволить данным скопиться, то их уже никогда не удастся оттуда вычитать. проверяем : Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
кажется работает. нет ? или я что-то просмотрел ? зы. статья полезная. хотя злобная и "хайповая" ... |
|||
:
Нравится:
Не нравится:
|
|||
19.04.2018, 20:26 |
|
пятничная задачка
|
|||
---|---|---|---|
#18+
а вот с учетом иерархии все грустно: 1. using сделали, а научить ему планировщик забыли. даже без tableoid: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Код: 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.
c row все грустно: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Код: 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.
хотя если оставит его на речек: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Код: 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.
2 вопроса. 3 вопроса 1. зачем забыли юзинг 2. есть ли (более) элегантное решение ? 3. у кого-нть под рукой есть трешовая иерархия на 100--1000 миллионников от гб ? ...4. нет ли готового системного типа для пары табоид-тид ? так шобы планер его узнавал ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 07:52 |
|
пятничная задачка
|
|||
---|---|---|---|
#18+
qwwq, а в предложенном решении же не линейное время получается? следующая итерация будет читать уже удаленные строки пока не придет автовакуум и не почистит их. скорее надо по диапазонам ctid читать (можно предварительно создать таблицу с диапазонами и удалять записи оттуда при чтении), правда пока будем читать кто-то в уже пройденные диапазоны может записать данные и в одной пачке получится не фиксированное число строк. хотя в 9.6+ можно заставить автовакуум просто сильно чаще по таблице ходить и не заморачиваться. задача по идее решается просто партициями (если данные insert only), отцепляем нужную партицию, читаем по кускам по id, а потом drop/truncate. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 08:48 |
|
пятничная задачка
|
|||
---|---|---|---|
#18+
Alexiusqwwq, а в предложенном решении же не линейное время получается? следующая итерация будет читать уже удаленные строки пока не придет автовакуум и не почистит их. скорее надо по диапазонам ctid читать (можно предварительно создать таблицу с диапазонами и удалять записи оттуда при чтении), правда пока будем читать кто-то в уже пройденные диапазоны может записать данные и в одной пачке получится не фиксированное число строк. хотя в 9.6+ можно заставить автовакуум просто сильно чаще по таблице ходить и не заморачиваться. задача по идее решается просто партициями (если данные insert only), отцепляем нужную партицию, читаем по кускам по id, а потом drop/truncate.это макет. как мы выбираем топ 100 -- это еще можно определяться. важно чтобы после этого мы удаляли отработку близко к линейному. если это лог, как у постановщика, то у него наверняка есть индекс по ид лога и нет апдейтов. видимо джоб должен бежать по ид и разгребать. (там автор не смог добиться линейного удаления по индексу). пробежка по цтид с фиксацией достигнутого тоже хорошее решение. и да в 9.6 + нужно видимо включить вакуум . м.б. авто. м.б. -- в текст джоба. последним шагом. т.к. там он почти инкрементален. то, что можно нарезать на партиечки -- само-собой. но борьба за "ДЕЛЕТ ТОП 1000" ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 09:58 |
|
пятничная задачка
|
|||
---|---|---|---|
#18+
Alexius, вот тестируем индексный проход : Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
планчик Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 10:30 |
|
пятничная задачка
|
|||
---|---|---|---|
#18+
авторТам была не очень специфическая задача: раз в день переносить изменения из PostgreSQL в OLAP, для чего в PostgreSQL завели заполняемую триггером таблицу change_log. Нужно было всего-то вычитать из нее данные и почистить ее. Так вот: мне не удалось найти решение, которое бы работало за линейное время и при этом умело вычитывать эту таблицу по частям. а весь последний день перенести, не? или брать последний ts из целевой таблицы ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 13:21 |
|
пятничная задачка
|
|||
---|---|---|---|
#18+
tip78авторТам была не очень специфическая задача: раз в день переносить изменения из PostgreSQL в OLAP, для чего в PostgreSQL завели заполняемую триггером таблицу change_log. Нужно было всего-то вычитать из нее данные и почистить ее. Так вот: мне не удалось найти решение, которое бы работало за линейное время и при этом умело вычитывать эту таблицу по частям. а весь последний день перенести, не? или брать последний ts из целевой таблицы это к автору по ссылке. весь день может быть очень велик. обработка джобом может быть сложной. чтобы не поставить колом используемый инструмент (пж, длинные транзакции на котором, если он в режиме ОЛТП, более чем не приветствуются, чему посвящен весь хай по ссылке) -- обработку нарезают на части. примерно такой подход\паттерн при кодировании джобов. убер на этом спалился. (что там невнятно проборматывается). на наличии сверхдлинных транзакций при наличии склонных к раздутию индексов часто обновляемых табличек. для пж это очень неудачный режим. индексы м.б. раздуты в 100-и раз. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 13:37 |
|
пятничная задачка
|
|||
---|---|---|---|
#18+
ну тогда... tip78или брать последний ts из целевой таблицы ^ повторить 24 раза ^ зы: я читал эту статью а ещё смотрел видео выступления кого-то из убера по итогу сделал вывод, что в убере захватили власть рукожопики, поэтому там всё как-то не сложилось.. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 14:22 |
|
пятничная задачка
|
|||
---|---|---|---|
#18+
tip78, блин, задача: сэмулировать "ДЕЛЕТ ТОП 1000" в пж. за приемлемое время. подзадача -- то же с иерархией вместо сингла. подвопросы -- какого хера оптимайзер знает только про цтиды, но не про тейблоиды и их компаунды с цтидами. например //* у подвопроса есть история и супербаг был на этом деле в форейнг-дата-враппере пежовом. или почему юнион не умеет цтид--скана. какая редиска его не обучила ? почему не наказан ? ну и т.д. а задача с линейным временем в пж делается на ротирующихся партициях. это не так интересно. я как-то присматривался нельзя ли таким револьверным способом "уберовские случаи" обслуживать. при некоторых допущениях о природе вещей -- вполне можно. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.04.2018, 22:38 |
|
пятничная задачка
|
|||
---|---|---|---|
#18+
qwwqподвопросы -- какого хера оптимайзер знает только про цтиды, но не про тейблоиды и их компаунды с цтидами. например //* у подвопроса есть история и супербаг был на этом деле в форейнг-дата-враппере пежовом. или почему юнион не умеет цтид--скана. какая редиска его не обучила ? почему не наказан ? ну и т.д. на это вроде тот же самый Фролков ответил так: постгрес это не оракл, который может нанять 2000 индусов на разработку с разработчиками там туго, поэтому они сосредотачиваются на самых актуальных задачах, про которые больше всего запросов ... |
|||
:
Нравится:
Не нравится:
|
|||
21.04.2018, 00:04 |
|
пятничная задачка
|
|||
---|---|---|---|
#18+
tip78, тут фенечка в том, что пж -- не оракл в том смысле, что там где в пж работающий синтаксис -- у оракла сидит цельный патентованный том, на цепи, и все его активно аскают. забава "аск том" называется. пока было так -- любителей пж росло. (по ссылке эвона пара мсскльщиков посрались на эту тему -- про прозрачность языка). а число индусов вторично там кстати автор так и не въехал, насколько они лажают с "аналогиями" прилагая мерку инно-беды к пж. https://habrahabr.ru/company/devconf/blog/353682/#comment_10768556 т.е. как уберовцы изначально переврали про "вторичные индексы" (волосы дыбом вставали), так последыши на головах и стоят. вместо того чтобы похерить эту постыдную псевдоаналогию. адын мишатюрин бъёдца с немчурой. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.04.2018, 20:43 |
|
|
start [/forum/topic.php?fid=53&msg=39634025&tid=1995813]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
55ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 20ms |
total: | 175ms |
0 / 0 |