Здравствуйте!

База весит 35 Гб, временные файлы 100Гб

Как можно их почистить?

Проблема в том, что делаю бэкап средствами postgresql, но при восстановлении базы требует эти 100Гб избыточных данных...

собственно как их очистить в текущей работающей базе

чтобы бэкапы следующие создавались без избыточности...

Зато постгре бесплатный...

Что такое "временные файлы" в контексте постгреса?

Видимо речь про временные файлы, которые создаются на время создания индексов

вот скриншот
https://hdd.tomsk.ru/desk/hvdlkund#

(6) откуда это чудо?

(7) pgadmin

похоже, сами файлы временные тут лежат, но счетчик их все равно не обнуляется

C:\Users\USR\AppData\Roaming\1C\1cv8\eebbc626-349c-4ed0-8e9d-2b4494d8fc4f

(8) (9) в том каталоге уж точно не постгресовские файлы

(10) ну пусть там кэш базы, тем более тогда... как временные файлы постгриса почистить...

(11) ты-бы хоть имя каталога в котором столько "добра" сообщил

(3) субд и ОС всегда должны быть бесплатными, особенно для обычных пользователей ;)

(11) я поищу, но прикол в том, что на диске этих 100Гб физически не занимается, но при восстановлении из бэкапа место начинает жрать...

(13) Зато админы тогда получаются дорогими. И тут ещё посчитать надо, что выгодней.
И да, ты свою работу тоже бесплатно продаёшь?

(15) А я не помню, чтобы пользователи платили за ОС и СУБД - за них это делает компания-работодатель.

(16) Компания-рабодатель в данном случае выступает в роли пользователя.

(0)
В процессе работы 1С накапливает туеву хучу всякого хлама в своих временных каталогах.
При перезапуске сервера, 1С удаляет свои временные файлы.
По-моему, помогает не перезапуск службы, а именно перезапуск всего сервера. Тут надо проверять. Попробуйте сначала службу перезапустить.

П.С.
В накоплении большого количества и объема временных файлов может быть и виновата не только лишь платформа, но и прикладные программисты.
Если, например, в коде используются что-то типа "ПолучитьИмяВременногоФайла", потом в этот файл что-то записывается, а потом программист не озадачивает себя удалением этого временного файла, то этот файл так и будет болтаться в каталоге временных файлов на сервере 1С. Тут см. выше, что я написал в данном посте.

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

И постгрес тут совершенно ни при чем. Как и любая другая СУБД поддерживаемая 1Сом.

(3)
Кстати, мы на нескольких проектах используем постгрес из коробки.
Пока никакого негатива нет.
Может быть, проекты не очень нагруженные, а может, просто достаточный запас железа имеется.

(6) По-ходу, это статистика за период, а не текущий размер. То есть ты погоду смотришь.

Еще спроси, где почистить кортежи, а то их что-то дофига возвращается.

спасибо за ответы :)

Восстанавливаешь как, через pg_restore?

И точное сообщение об ошибке напиши.

восстановлиение:

1) создаем БД в pgadmin

2) "C:\Program Files\PostgreSQL\11.5-7.1C\bin\pg_restore.exe" -c -h localhost -U postgres -d 123 "F:\backup\Backup_123\123_2021-02-20_14-44-33.backup"

3) конфигурация
"C:\Program Files\PostgreSQL\11.5-7.1C\bin\psql.exe" --host localhost --port 5432 --username "postgres" --command "\COPY public.config FROM 'F:\backup\Backup_123\conf_123.config' WITH BINARY;" --dbname="123"

нету ошибок, все работает, просто в процессе он восстанавливает временные файлы судя по всему, и места на диске требуется значительно больше

около 100 гигабайт в процессе восстановления, а при завершении 35-45 гигов занимает сама база и место как бы освобождается....

проблема что нафига ему эти 100 гигов в процессе восстановления, может перед бэкапом как-то чистить этот мусор можно, вот в чем вопрос

(28) Я не настоящий сварщик, но вроде у PG есть функция vacuum - это не оно?

(29) попробую

(28) Я тоже не настоящий сварщик, но уверен что vacuum и "временные файлы" тут не причем. Думаю что дело в другом.
Этот способ бэкапа/восстановления довольно калечный в сравнении с сиквельным. Это не бинарный бэкап данных, а набор инструкций постгри, выполнение которых приведет БД в нужное состояние.
Подозреваю, что он может быть больше самой базы. То есть постгри нужно дополнительное место на разархивацию этого мегабэкапа, а потом по инструкциям из него он начинает базу заполнять. Ради интереса можно попробовать сделать бэкап без опции сжатия и посмотреть сколько он занимает. Скорее всего - это оно и есть.
ЗЫ. В бесплатном постгри есть и бинарный бэкап, но он бэкапит целиком кластер. В серьезном продакшене постгри так и юзают - по отдельному кластеру на базу. И бэкапить хорошо и настройки постгри можно затюнить под конкретный профиль нагрузки этой базы.

И кстати, почему в 2021 году 100Гб стало проблемой? Что винты, что SSD меньше терабайта не покупаются.

(29) не оно

(28) никакие временные файлы не восстанавливаются, вы понимаете как строятся индексы, к примеру? Можно сравнительно быстро но нужны темпы на время сортировки, а можно медленно и  печально чуть лучше чем пузырьковым методом

(3) просто не настраивался у.нас

https://qastack.ru/dba/111187/postgresql-size-of-temporary-files
Они уже нигде не лежат, это просто статистика.

Бэкап без сжатия гораздо быстрее. Сжать потом, при необходимости, можно чем-нибудь многопоточным.