Есть ли в PostgreSQL аналоги таких фичь из MSSQLSERVER

Коллеги, приветствую!
Тут у нас начал подниматься вопрос о миграции софта на "отечественные" платформы.
Предварительно прорабатываем вопрос.

Может кто-то имеет опыт и в MSSQLSERVER?
Есть ли в постгрессе аналог Filetable и вообще - Filestream? (как выяснилось, в одном из проектов очень активно используется)
Если есть, то в каком направлении копать, бросьте пару ключевых слов!
И еще:
Есть ли аналог resource governor, можно ли как-то выделить конкретному пользователю конкретный пул ресурсов, по диску и процессору?
Есть ли аналог колоночных индексов? Интересует Clustered columnstore со сжатием (в проектах встречаются таблички по 1-15 млрд. записей, их тяжко хранить в rowstore)
Секционирование есть, это я уже увидел, мне понравилось больше, как оно сделано. Как я понимаю, секцию в секционированной таблице в постгрессе можно "налету" заменить на таблицу аналогичной структуры, с данными, подпадающими под параметр секционирования?
В нескольких проектах (это всякие СЭДы) используется хранение всяких ворд/эксель документов в filestream, и полнотекстовый индекс по их содержимому поверх всего этого. Есть что-нибудь в таком духе?

Коллеги, если можно, кто знает, буквально по паре слов. По типу: Есть, называется так-то. Если ссылкой ткнете, будет вообще праздник.

Спасибо!

0

FLASHBACK TABLE? Нет. https://dba.stackexchange.com/... ry/362#362

Добавлено через 2 минуты

Сообщение от uaggster остгресс же версионник.

Там внутренняя структура датафайлов такова, что периодически сверяется номер самой ранней транзакции и "уплотняются" старые строки как внутри страницы датафайла, так и периодически ходит процесс автовакуума.

0

Версионность postgres это не то, она тут используется для обеспечения того, чтобы читающая транзакция не блокировала пишущую.
M$SQL был блокировочником, помню эти грязные чтения(nolock).
Пользовательского версионирования нема, надо делать самому или уходить от него.
И надо понимать, что при интенсивных изменениях таблица будет занимать много места.

0

Сообщение от oktogen И надо понимать, что при интенсивных изменениях таблица будет занимать много места.

Рецепт давно известен: не создавать длительных транзакций (чтобы не удерживать старые версии строк), поиграть с параметрами автовакуума и сделать, чтобы он запускался почаще.

0

Сообщение от oktogen И надо понимать, что при интенсивных изменениях таблица будет занимать много места.

Это понятно. Но иногда - бывает нужно.
Понятно, значит, как обычно триггером.

0

Сообщение от uaggster Темпоральная таблица - это такая, которая хранит все свои изменения, и можно сделать Select данных из таблицы по состоянию на какую-то дату. Т.е. сегодня, например 31.08.2023. Системное версионирование на таблице включено, к примеру, 01.01.2023. Мы можем сделать select из таблицы с указанием даты версионирования 10.08.2023, то результатом будут данные, как если бы мы находились в 10м августа. Постгресс же версионник. У него такие штуки должны, наверное, из коробки быть?

Из коробки такой фичи нет.
Но, если вы организуете у себя в системе непрерывное архивирование (что в принципе рекомендуется делать в решениях с повышенной надежностью), то восстановление таблицы возможно с использование PITR (point-in-time recovery). Примерный подход такой: разворачиваем какой-то старый бакап (он у нас должен быть) на отдельном инстансе, настраиваем recovery в postgresql.conf (указываем примерно эти опции), стартуем инстанс. Конечно, это не совсем быстрый и удобный метод, но бывает полезно, если кто-то по нерадивости или "по ошибке в коде сделал TRUNCATE TABLE" )) и закомитил транзакцию.

0

Сообщение от grgdvo Из коробки такой фичи нет. Но, если вы организуете у себя в системе непрерывное архивирование (что в принципе рекомендуется делать в решениях с повышенной надежностью), то восстановление таблицы возможно с использование PITR (point-in-time recovery). Примерный подход такой: разворачиваем какой-то старый бакап (он у нас должен быть) на отдельном инстансе, настраиваем recovery в postgresql.conf (указываем примерно эти опции), стартуем инстанс. Конечно, это не совсем быстрый и удобный метод, но бывает полезно, если кто-то по нерадивости или "по ошибке в коде сделал TRUNCATE TABLE" )) и закомитил транзакцию.

Нет, там смысл в другом.
Например, есть некая запись в базе (опять в приложении к СЭД). Уполномоченные, подчеркиваю, пользователи эту запись меняют.
Нужно восстановить порядок изменений и состояние записи на какой-то момент времени.
Причем оперативно, по типу, а что там 1 августа было.
Ну, решается это вытеснением предыдущего состояния записи в некую историческую таблицу. Как вариант.
Но нужен триггер (например), что плохо сказывается на производительности. Да и опасность дедлоков и всё такое.

Но, в принципе, это не блокирующая фича. Триггером всё решается.

0