Кое что хотел знать о PostgreSQL, но боялся спросить

128 ГБ ОЗУ, если у меня кластер 100ГБ. И все

Зависит от того, какие запросы. Может у тебя там на каждый чих временная таблица для сортировки создаётся на 100Гб. Тогда никакой памяти не хватит.

В общем

В общем

объем превышающий...объем

будет ли какой то прирост производительности.

Второе утверждение,

И это далеко не всё.

починил, бывает полезно написанное вслух перечитать, как то в этот раз не догадался

одинеска то наврятли, она скорее много их создает но небольших

она скорее много их создает но небольших

Дык они и неявно создаются, если запрос по-другому нельзя выполнить. Я к тому, что недостаточно просто сделать память больше чем объём данных, нужно ещё чтобы было где промежуточные результаты хранить, а их может быть дохренилион. Проще всего наверное в натуре проверить, если есть возможность. А так просто гадание получается.

надо ка кто дать ответ на вопрос: как спрогнозировать рост объема временных таблиц 1с

а ты знаешь кого из одинесников кастануть?

На https://infostart.ru/ эти вопросы так же любимы как верблюжья колючка программистам 1С …
Пережевывать тысячу раз одно и тоже не хочется.

Ну то есть не SSD покупать за 100 тыров, а 128 ГБ ОЗУ, если у меня кластер 100ГБ. И все?

Ну, квантовый компьютер купите что-ли …
Не пожалеете.

Пост ироничен от того, что у вас ни какой конкретики в вопросах нет, соответственно и отвечать нечему.

Персонально для 1С - нет, не поможет.. просто запустите тесты гилева например, там база 30Мб, и… посмотрите загрузку сервера.

вот что мой коллега говорит:

Я спрашиваю:

как спрогнозировать рост объема временных таблиц у 1с?

Он отвечает:

самопроизвольный? или от чего? вообще от нагрузки зависит, т.е. групповое проведение документов сразу аццке увеличит временные таблицы и мусор в основных таблицах плюс практически все индексы становятся не актуальными и кэш скривляется

Думаю с таким поворотом событий можно сразу начинать переиндексировать базу

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

ну 200 клиентов могут работать одновременно, вроде многоядерность спасает, и постгрес и сервер 1С в несколько процессов работают

да но на постресе соединения не от количества 1С юзеров а от количества баз, я же не писал про уходить на одноядерность в 2020 году это фантастика!

и да самая быстрая конфигурация для 1С это Microsoft SQL + механизм shared memory. Также сильно зависит как быстро клиент ответит, а там webkit.

у нас 2 года в проде конфигурация с линуксовыми серверами 1с и постгресом. Может оно и стало медленнее на некоторых задачах, но это ощутимо только по гилеву.

Не всегда. Тест Гилёва на одной и той же виртуалке с MSSQL + shared memory под Win2019 у меня выдал на одного попугая меньше, чем в той же виртуалке PostgreSQL подключеный через сокет под CentOS7. Что MSSQL с дефолтной конфой, что Postgres дефолтный, 12 от 1С. Платформа 8.3.18.

механизм shared memory

это я так понимаю тип подключения к серверу?

1. Да.

2. Так, но есть зависимость от ТТХ дисковой подсистемы.

ну да, тип подключения к серверу SQL

Вот бы сейчас документацию почитать, да ведь шуля?