|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Swa111, log_statement ddl включить и дальше по логу базы считать. или pg_stat_statements track_utility включить и с его помощью. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.06.2020, 22:18 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Случайно набрёл на эту тему. Работаем с MS-SQL. Часто применяем такой подход: Шаг 1. Во временные таблицы набиваем сырые данные (иногда их много). Шаг 2. При необходимости с этими таблицами проводим какую-то обработку (как минимум синхронизацию ссылок между мастер-детейл). Шаг 3. Отправляем запрос в котором: открываем транзакцию, переливаем данные в основные таблицы, закрываем транзакцию. Т.к. из-за импортозамещения придется поддерживать и PG, то теперь в размышлениях... Можно конечно под эти цели завести постоянные и внутри "разводить" по сессиями, но не хотелось бы. Подскажите пожалуйста, где посмотреть какие у PG проблемы с временными таблицами. В гугле не банили и честно пытался поискать. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 07:56 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Юрий Зиновьев Случайно набрёл на эту тему. Работаем с MS-SQL. Часто применяем такой подход: Шаг 1. Во временные таблицы набиваем сырые данные (иногда их много). Шаг 2. При необходимости с этими таблицами проводим какую-то обработку (как минимум синхронизацию ссылок между мастер-детейл). Шаг 3. Отправляем запрос в котором: открываем транзакцию, переливаем данные в основные таблицы, закрываем транзакцию. Т.к. из-за импортозамещения придется поддерживать и PG, то теперь в размышлениях... Можно конечно под эти цели завести постоянные и внутри "разводить" по сессиями, но не хотелось бы. Подскажите пожалуйста, где посмотреть какие у PG проблемы с временными таблицами. В гугле не банили и честно пытался поискать. Для такой задачи и в pg временные таблицы вполне нормально подходят и используются. Только нало в pg не забывать analyze временной таблицы делать после шага 1 (и если вы там меняли очень много данных внутри). Проблемы начинаются когда через временные таблицы начинают OLTP-like задачи решать создавая и удаляя их сотнями в секунду (и используя фактически как замену переменным уровня сессии). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 09:03 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Maxim Boguk, большое спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 11:18 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Юрий Зиновьев Работаем с MS-SQL. Часто применяем такой подход А какой баг в MS SQL вы обходите таким кривым костылём? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 14:51 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Юрий Зиновьев Работаем с MS-SQL. Часто применяем такой подход А какой баг в MS SQL вы обходите таким кривым костылём? а почему сразу баг то? загрузка сырых данных сначала в временную таблицу это стандартная РЕКОМЕНДУЕМАЯ практика при ETL задачах на любой базе (что оракл что pg что mssql) , там чистка-преобразование-валидация и уже после - загрузка чистых данных в постоянные таблицы (там вполне 10% может остаться от того что залили). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 17:21 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
тоже актуально PostGres в Azure И тоже в мс-скл часто юзаел #Tmp таблицы чаще всего когда сложная логика - то в SP разбивал логику на куски #tmp1 , #Tmp1 , #tmp3 ... (а иногда и глобальные ## чтобы видеть можно было ) - но это больше для ETL чтобы видеть где и когда что упало и быстро догрзуить кусок вопрос временные таблицы в Azure не имеют никаких отличий от станд. постгреса ? ps а вобще кто-то с PostGres Azure работает ? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2020, 18:07 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Maxim Boguk загрузка сырых данных сначала в временную таблицу это стандартная РЕКОМЕНДУЕМАЯ практика при ETL задачах на любой базе (что оракл что pg что mssql) , там чистка-преобразование-валидация и уже после - загрузка чистых данных в постоянные таблицы (там вполне 10% может остаться от того что залили). Ну, у ETL-то преобразование это T, которое стоит ещё до до L. Чистка и валидация это да, ништяк применение при загрузке данных извне. Но у меня почему-то создалось впечатление, что ТС грузит во временные таблицы данные из самой базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2020, 14:43 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Тоже столкнулись с тем, что сильно разрослась в первую очередь pg_attribute и другие таблицы из pg_catalog. А какие альтернативы есть временным таблицам? Переменные не подходят. Требуется использование многоколоночных структур. Данные используются только в пределах транзакции, так что видны только данные, которые данной транзакцией вставлены. Пока заменили временные таблицы на постоянные unlogged с той же структурой, что была у временных. В продакшн пока не выкладывали. На тестовых средах таблицы занимают максимум 4 блока (32Kb). Не надо ли в таблицы добавлять колонки (и индексом по ней) с константами в пределах транзакции и фильтрация по этой колонке, для более быстрого доступа. Или при разростании таблицы до какого размера потребуется такая дополнительная колонка с индексом? Или она не поможет? Массив структур вряд ли получится использовать, поскольку используется выборка по некоторым условиям, в том числе в соединении с другими таблицами ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2022, 00:45 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Kr_Yury, Массив структур вполне рабочий вариант, выборка по условиям и соединение с другими таблицами решается через unnest c WITH ORDINALITY. Работает хорошо до тех пор пока не нужно передавать массив в другие процедуры и сам массив не большого размера. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2022, 11:37 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Swa111, спасибо. В нашем случае временные таблицы содержат относительно мало данных. Попробую одну из них заменить на массив структур. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2022, 13:49 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Swa111 Kr_Yury, Массив структур вполне рабочий вариант, выборка по условиям и соединение с другими таблицами решается через unnest c WITH ORDINALITY. Работает хорошо до тех пор пока не нужно передавать массив в другие процедуры и сам массив не большого размера. А какая собственно проблема передать массив в другую процедуру то? -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2022, 21:05 |
|
Хороший тон создания временных таблиц в PostgreSQL
|
|||
---|---|---|---|
#18+
Kr_Yury Тоже столкнулись с тем, что сильно разрослась в первую очередь pg_attribute и другие таблицы из pg_catalog. А какие альтернативы есть временным таблицам? Переменные не подходят. Требуется использование многоколоночных структур. Данные используются только в пределах транзакции, так что видны только данные, которые данной транзакцией вставлены. Пока заменили временные таблицы на постоянные unlogged с той же структурой, что была у временных. В продакшн пока не выкладывали. На тестовых средах таблицы занимают максимум 4 блока (32Kb). Не надо ли в таблицы добавлять колонки (и индексом по ней) с константами в пределах транзакции и фильтрация по этой колонке, для более быстрого доступа. Или при разростании таблицы до какого размера потребуется такая дополнительная колонка с индексом? Или она не поможет? Масссив структур вряд ли получится использовать, поскольку используется выборка по некоторым условиям, в том числе в соединении с другими таблицами Есть интересный вариант когда вы при создании коннекта создаёте временную таблицу 1 раз и далее её используете до победы. Если вы её сделаете с DELETE ROWS то она ещё и будет автоматически после транзакции очищаться. При условии долгоживущих конектов к базе - это наверное самое простое решение не требующее серьёзных переделок бизнес-логики. НО лучше конечно 32kb через массив стуктур (точнее типизированных row()) передавать а не через таблицы + unnest для разворота в таблицу. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
08.02.2022, 21:09 |
|
|
start [/forum/topic.php?fid=53&gotonew=1&tid=1993666]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
30ms |
get topic data: |
13ms |
get first new msg: |
8ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
others: | 265ms |
total: | 415ms |
0 / 0 |