Скачал postgresql-8.2.6-2.1C с сайта 1с, установил, загрузил в него базу. Попробовал наиболее "тяжелые" отчеты, которые в mssql 2000 дико тормозили. В постгресе они стали просто летать. Однако.
Когда-то разбирался с причинами торможения mssql, трассировал, смотрел планы выполнения. Пришел к выводу что mssql часто не может построить оптимальный план выполнения для генерируемых 1с запросов - получаются сплошные nested loops. Похоже, оптимизатор в постгресе получше микрософтовского в sql2000.. Правда, sql2005 не пробовал.

С MS SQL не сравнивали, но Postgres на чтение реально гуд. Вот только на запись, похоже, тупит. Еще по этому параметру интересно было бы посмотреть.

Кстати, как я заметил, если в postgresql.conf задать enable_nestloop = off, то скорость работы pgsql еще сильнее возрастает. Очевидно, запросы формируемые 1с провоцируют использование nested loops, в postgre в меньшей степени, в mssql - в большей. Интересно, в mssql можно вот так отключить использование nested loops?

(1) Ручные блокировки не помогают?

(2) а чо ж должен сервер возвращать, если нестед лупс ему запретить, а по другому запрос он исполнить не сможет? :)

Зы. 1С под сиквелем намного быстрее чем под чем-либо еще. Естественно, под 2005 сиквелем. Не очень же умно в самом деле юзать программу семилетней давности и жаловаться на то, что она тормозит. Хотя, у постгреса огромный потенциал, ибо версионник. Вот только осилят ли нуралиевцы его?

(4) Попробовал все planner metod поставить в OFF - сервер работает, запросы выполняет, только оооочень медленно. Очевидно, у сервера есть какой-то "базовый" метод выполнения запросов, возможно жутко неоптимальный. А все остальные - опционально, для ускорения. Только вот nested loop в применении к 1с чаще замедляет, чем ускоряет. Короче, я убедился - самые лучшие результаты postgre + v8 выдает, когда все методы планировщика включены (по умолчанию), кроме enable_nestloop.
"Не очень же умно в самом деле юзать программу семилетней давности и жаловаться на то, что она тормозит" - а что делать? Если параллельно ведется учет в v7.7, то тут переход на sql2005 с патченьем бинарников тоже не совсем прямое решение.

Полный расчет документа начисления зарплаты 950 человек на постгре с отключенными nested loops выполнился за 45 секунд, причем заполнение табличных частей заняло всего 9 секунд. На mssql только заполнение табличных частей заняло 3.5 минуты, а рассчитывался он 4 минуты. На одном и том же сервере. Отличие практически на порядок.
По-моему, разработчикам платформы 1с следовало бы учесть этот факт, и посылать запросы на mssql с соответствующими параметрами оптимизации (хотя бы тупо отключая nested loops). А может они это в запасе держат? Как тот чукча из анекдота который бревно с собой нес, чтобы когда медведя встретит - бревно бы бросил и быстро-быстро побежал :) Вот наступят для 1с черные дни, а они раз - и быстродействие на порядок поднимут.. :)

(6)Думаю, это не совсем корректный показатель. Многое зависит еще и от того, насколько сложным является расчет на конкретном предприятии. Вполне может оказаться, что простой тупой пересчет на postgres может оказаться быстрее. Однако, хотелось бы знать как обстоят дела с различными настройками и сложными документами расчета.
И еще. Не совсем понятно на какой операционной системе установлен postgres.

угу..представляю как сотня юзеров сидит на постгре..

(4)простите моё незнание,а 2005 мс скл разве не версионник?

(8) А что, сотня юзеров не может сидеть на постгре?

(8) тут уже мелькал чувак с 50 юзеров на УПП в постгре

(10) сидят, но туго. Ждем стабильной ветки-потомков 15-го (управляемые блокировки)

(9),(10) из за плохо управляемых блокировок(на уровне постгре)
большое количество юзеров , одлновременно работающих в постгре, очень мало.
во всяком случае точно менее чем максимально может потянуть мс скл .
Но эт фигня. У меня только один раз был случай использования постгре.
И мне очень бы хотелось посмотреть как работает там оптимизатор. Потому что есть сомнения что его там вообще нет как такового.
Работу того жэ кеша запросов я так и не увидел.
В общем много всего

(7) База ЗУП относительно небольшая - около 1000 сотрудников, порядка полусотни подразделений. Начата в 2008 году. Количество пользователей - не больше десятка. Сервер - win2003Standart(2 ксеона 2.2ГГц, 4Гб озу), на нем установлены sql2000 Standart и postgresql-8.2.6-2.1C. На таких исходных данных у меня самым быстрым решением оказался postgre с отключенным nested loop.

(13)Ты не понял. Под "сложностью" я понимаю сложность учета в самой ЗУП. Уровень детализации аналитики. Сколько, например, у вас записей в документе "Отражение зарплаты в регл.учете"?

(14) В документе "Отражение зарплаты в регл.учете" около 5 тысяч записей (проводок).

У нас более 35 тысяч записей. Интересно, как долго будет все это расчитываться на postgres. Да еще сравнить postgres под Linux и под Windows 2003

(6) А сколько записей в этом документе?

(13) Надо будет попробовать, у меня практически то же самое.

(13) В контексте (5) вопрос: во время тестов оба sql-сервера ничем загружены не были? По одной базе в каждом и тесты неодновременные?

щас обновили постгри до 8.2.5 - ранее ввод возврата поставщику на основании поступления в 500 строк занимал минут 20-ть, после обновления - до минуты... но еще требует проверки, сегодня тестировать буду
(10) если ты обо мне, то не нравится мне слово "чувак"...

(17) В табличной части Начисления около тысячи строк - как правило у сотра по одному плановому начислению(оклад/тариф/сделка), редко у кого есть надбавки. Порядка 1000 строк НДФЛ. Около 300 строчек плановых удержаний(профком, алименты и т.п.).
(19) "во время тестов оба sql-сервера ничем загружены не были? По одной базе в каждом и тесты неодновременные?"
Физически это один сервер. Тесты проводились в часы отсутствия нагрузки, разумеется на ms и pg не одновременно. Причем повторял несколько раз - результаты совпадают.

(21)Ты в (6) писал, что 950 человек у тебя считалось... Если все было в одном документе, то должно быть минимум 5000 строк в начислениях.

(22) "950 человек у тебя считалось... Если все было в одном документе, то должно быть минимум 5000 строк в начислениях"
Это почему еще?

(23)Простая арифметика (Оклад,Премия,РК,СН, доплата за питание и пр.)*950 = более 5 тысяч и это только обыкновенные окладники... Уже не говоря про рабочих, где есть куча переработок, доплат за совмещение,вредность и пр., вахта и т.д.

У нас в плановых только основное начисление и иногда персональная надбавка. Премии в ЗУП2.5 вообще не могут быть плановыми. Районных коэффициентов не применяется, доплаты вводятся разовыми начислениями.

(20)А постгри новую где можно скачать?

(26) Я качал на users.v8.1c.ru

(8) Нет 2005 сиквель не версионник. Хотя, некоторые возможности версионника в нем появились.

(27)8.2.5 качал? Сейчас зашел, что-то нету...

http://users.v8.1c.ru/Platform_8_2_6_21C_pwn_s.aspx