powered by simpleCommunicator - 2.0.40     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Хороший тон создания временных таблиц в PostgreSQL
13 сообщений из 38, страница 2 из 2
Хороший тон создания временных таблиц в PostgreSQL
    #39965458
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swa111,

log_statement ddl включить и дальше по логу базы считать.
или pg_stat_statements track_utility включить и с его помощью.
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40020207
Случайно набрёл на эту тему. Работаем с MS-SQL. Часто применяем такой подход:
Шаг 1. Во временные таблицы набиваем сырые данные (иногда их много).
Шаг 2. При необходимости с этими таблицами проводим какую-то обработку (как минимум синхронизацию ссылок между мастер-детейл).
Шаг 3. Отправляем запрос в котором: открываем транзакцию, переливаем данные в основные таблицы, закрываем транзакцию.

Т.к. из-за импортозамещения придется поддерживать и PG, то теперь в размышлениях...
Можно конечно под эти цели завести постоянные и внутри "разводить" по сессиями, но не хотелось бы.

Подскажите пожалуйста, где посмотреть какие у PG проблемы с временными таблицами. В гугле не банили и честно пытался поискать.
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40020219
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Юрий Зиновьев
Случайно набрёл на эту тему. Работаем с MS-SQL. Часто применяем такой подход:
Шаг 1. Во временные таблицы набиваем сырые данные (иногда их много).
Шаг 2. При необходимости с этими таблицами проводим какую-то обработку (как минимум синхронизацию ссылок между мастер-детейл).
Шаг 3. Отправляем запрос в котором: открываем транзакцию, переливаем данные в основные таблицы, закрываем транзакцию.

Т.к. из-за импортозамещения придется поддерживать и PG, то теперь в размышлениях...
Можно конечно под эти цели завести постоянные и внутри "разводить" по сессиями, но не хотелось бы.

Подскажите пожалуйста, где посмотреть какие у PG проблемы с временными таблицами. В гугле не банили и честно пытался поискать.


Для такой задачи и в pg временные таблицы вполне нормально подходят и используются.
Только нало в pg не забывать analyze временной таблицы делать после шага 1 (и если вы там меняли очень много данных внутри).

Проблемы начинаются когда через временные таблицы начинают OLTP-like задачи решать создавая и удаляя их сотнями в секунду (и используя фактически как замену переменным уровня сессии).


--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40020277
Maxim Boguk, большое спасибо!
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40020405
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Юрий Зиновьев
Работаем с MS-SQL. Часто применяем такой подход

А какой баг в MS SQL вы обходите таким кривым костылём?
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40020501
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov
Юрий Зиновьев
Работаем с MS-SQL. Часто применяем такой подход

А какой баг в MS SQL вы обходите таким кривым костылём?


а почему сразу баг то?
загрузка сырых данных сначала в временную таблицу это стандартная РЕКОМЕНДУЕМАЯ практика при ETL задачах на любой базе (что оракл что pg что mssql) ,
там чистка-преобразование-валидация и уже после - загрузка чистых данных в постоянные таблицы (там вполне 10% может остаться от того что залили).



--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40020528
Гулин Федор
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
тоже актуально PostGres в Azure
И тоже в мс-скл часто юзаел #Tmp таблицы
чаще всего когда сложная логика - то в SP разбивал логику на куски
#tmp1 , #Tmp1 , #tmp3 ...

(а иногда и глобальные ## чтобы видеть можно было ) - но это больше для ETL
чтобы видеть где и когда что упало и быстро догрзуить кусок

вопрос временные таблицы в Azure
не имеют никаких отличий от станд. постгреса ?

ps а вобще кто-то с PostGres Azure работает ?
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40020790
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Maxim Boguk
загрузка сырых данных сначала в временную таблицу это стандартная РЕКОМЕНДУЕМАЯ практика при ETL задачах на любой базе (что оракл что pg что mssql) ,
там чистка-преобразование-валидация и уже после - загрузка чистых данных в постоянные таблицы (там вполне 10% может остаться от того что залили).

Ну, у ETL-то преобразование это T, которое стоит ещё до до L. Чистка и валидация это да, ништяк применение при загрузке данных извне. Но у меня почему-то создалось впечатление, что ТС грузит во временные таблицы данные из самой базы.
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Хороший тон создания временных таблиц в PostgreSQL
    #40132386
Kr_Yury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тоже столкнулись с тем, что сильно разрослась в первую очередь pg_attribute и другие таблицы из pg_catalog. А какие альтернативы есть временным таблицам? Переменные не подходят. Требуется использование многоколоночных структур. Данные используются только в пределах транзакции, так что видны только данные, которые данной транзакцией вставлены. Пока заменили временные таблицы на постоянные unlogged с той же структурой, что была у временных. В продакшн пока не выкладывали. На тестовых средах таблицы занимают максимум 4 блока (32Kb). Не надо ли в таблицы добавлять колонки (и индексом по ней) с константами в пределах транзакции и фильтрация по этой колонке, для более быстрого доступа. Или при разростании таблицы до какого размера потребуется такая дополнительная колонка с индексом? Или она не поможет?
Массив структур вряд ли получится использовать, поскольку используется выборка по некоторым условиям, в том числе в соединении с другими таблицами
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40132461
Swa111
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Kr_Yury,

Массив структур вполне рабочий вариант, выборка по условиям и соединение с другими таблицами решается через unnest c WITH ORDINALITY. Работает хорошо до тех пор пока не нужно передавать массив в другие процедуры и сам массив не большого размера.
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40132490
Kr_Yury
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swa111, спасибо.
В нашем случае временные таблицы содержат относительно мало данных. Попробую одну из них заменить на массив структур.
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40132678
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swa111
Kr_Yury,

Массив структур вполне рабочий вариант, выборка по условиям и соединение с другими таблицами решается через unnest c WITH ORDINALITY. Работает хорошо до тех пор пока не нужно передавать массив в другие процедуры и сам массив не большого размера.


А какая собственно проблема передать массив в другую процедуру то?

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
Хороший тон создания временных таблиц в PostgreSQL
    #40132680
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Kr_Yury
Тоже столкнулись с тем, что сильно разрослась в первую очередь pg_attribute и другие таблицы из pg_catalog. А какие альтернативы есть временным таблицам? Переменные не подходят. Требуется использование многоколоночных структур. Данные используются только в пределах транзакции, так что видны только данные, которые данной транзакцией вставлены. Пока заменили временные таблицы на постоянные unlogged с той же структурой, что была у временных. В продакшн пока не выкладывали. На тестовых средах таблицы занимают максимум 4 блока (32Kb). Не надо ли в таблицы добавлять колонки (и индексом по ней) с константами в пределах транзакции и фильтрация по этой колонке, для более быстрого доступа. Или при разростании таблицы до какого размера потребуется такая дополнительная колонка с индексом? Или она не поможет? Масссив структур вряд ли получится использовать, поскольку используется выборка по некоторым условиям, в том числе в соединении с другими таблицами


Есть интересный вариант когда вы при создании коннекта создаёте временную таблицу 1 раз
и далее её используете до победы.
Если вы её сделаете с DELETE ROWS то она ещё и будет автоматически после транзакции очищаться.
При условии долгоживущих конектов к базе - это наверное самое простое решение не требующее серьёзных переделок бизнес-логики.

НО лучше конечно 32kb через массив стуктур (точнее типизированных row()) передавать а не через таблицы + unnest для разворота в таблицу.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
13 сообщений из 38, страница 2 из 2
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Хороший тон создания временных таблиц в PostgreSQL
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]