Когда-то давным давно, при переводе 8.1 на постгрес существовала проблема блокировок при проведении, надо было переписывать процедуру проведения и переключать режим блокировок для большого количества работающих пользователей. Теперь собсно говоря вопрос, как с этим обстоят дела в 8.2 и 8.3 в гугле полно статей на эту тему, но они или старые, или переписанный копипаст старых статей. Мне интересно, эта проблема осталась, или 1с-неги по привычке кричат, что постгрес не тру? Хотелось бы выслушать мнение людей, которые действительно работали с подобной связкой, а не имхо предвзятых виндоузятников, для которых постгрес бяка по умолчанию, патамушта Линукс.

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

В 1С следует курить управляемые блокировки - это даже не обсуждается. И дело уж точно не в постгри.

Кто-то недавно написал, что некорректно nested loops обрабатывает и тупит. А в старых конфигурациях вложенных запросов еще порядком.

управляемые блокировки в свежей УПП навскидку присутствуют, но кажется это не решит проблему.

У нас серверами и выбором серверного софта занимаются админы. Много лет на сервере установлена линуксовая версия в связке с постгри.
Не совсем в курсе нюансов, а где-то есть хорошее и внятно описание проблем с эксплуатацией 1С на постгри ?

(4) По сети гуляют старые описания для 8.1 или копипаст из старых. Имхану конечно, но эти статьи сформировали негативное отношение к такой связке у 1с-негов, когда начинаешь спрашивать все трындят про блокировки, хотя если копать первоисточники подобного мнения, упираешься опять же в эти старые статьи. Интересует, как обстоят дела сейчас.

Как то юзали постгрес на автоматических блокировках с небольшой модификацией по источникам из инета - тормоза при перепроведении задним числом (30 сек.-2 мин вместо 5-10 сек. MS SQL) убили всякое желание экспериментировать

(6) Какая платформа? Чей постгрес ставили?

** подпишусь

хочу намутить на выходных схему с tablespace под 1с на ram-диске, с синхронизацией ко второму инстансу pgsql на той же машине, но с записью на настоящий диск

зачем? на дешевом хостинге недоступен ssd, вот зачем

+ в продолжение, у постгреса есть огромный минусище.
Когда падает винда и нет бэкапа - не многие знают как восстановить базу.
Только после обкатки такого восстановления можно залазить :) А про бэкапы - да слышали...Только когда они нужны диск с ними обычно был забит месяц назад и актуальных нет ))

(9) И постгрес, конечно, виноват, Что и винда упала и бэкапов нету...

(10) ну бэкап дневной давности в средней конторе к примеру 1С-нику обычно нахрен не нужен )
При MS SQL такой вопрос не поднимается обычно.

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

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

что? у нас УПП, 100 пользователей. работает постгре 9.2

100 одновременно работающих. всего 160

(15) ну мы то тебе не верим что все нормуль, пока данные apdex не увидим :)

да не верьте, мне-то что, я из этого профит не извлекаю :)

(9) Ну постгрес на винде это конечно не тру, родная ось для него линукс. В этом то и есть основная идея перевода 1с на постгрес. Просто когда начальство увидело ценник на лицензию виндовс сервер, лицензии на подключение к серверу, лицензии на скуль я понял, что нового сервера не будет. На тестах всё отлично, но тесты тестами, а вот как всё взлетит, когда подключатся 150 пользователей, вопрос интересный.

Я уже писал неоднократно - у постгреса тупой оптимизатор запроса. Тупость заключается в том, что он применяет nested loop при соединении с подзапросом (виртуальной таблицей 1с). Поскольку на момент составления плана запроса неизвестно, какой будет размер таблицы, возвращенной подзапросом, постгрес слишком оптимистично предполагает, что подзапрос вернет очень мало строк, и надо применять nested loop. В 1с это чаще всего не так.

Вот темы на форуме стоит почитать
https://www.google.ru/webhp?sourceid=chrome-instant&ion=1&espv=2&es_th=1&ie=UTF-8#newwindow=1&q=enable_nestloop+site:forum.mista.ru

(20) Стоит, я в некоторых из них даже участвовал. Но решения, которое бы 100% работало на самом деле нет. Если отключать nested loop полностью для сервера замедляет работу в целом, если не отключать - есть риск наткнуться на дикие тормоза в частности.

(19) Причем тут тупой оптимизатор, вы описываете стандартный алгоритм любого оптимизатора при соединении с подзапросом, который непонятно что возвращать будет. И такого в 1С мало.

Почитай по ссылкам темы с неадекватным поведением постгреса протим скуля :)

(22) "вы описываете стандартный алгоритм любого оптимизатора при соединении с подзапросом"
Только вот почему-то mssql и db2 не делают nested loop, а постгрес - делает.
"И такого в 1С мало."
Сейчас в основном это учитывают, но старого кода еще достаточно, с тех времен, когда временных таблиц еще "не придумали")

(24) Конечно же и ms sql и db2 тоже могут залупить нестедлупс.

элементарный пример:
ВЫБРАТЬ
    ПоступлениеТоваровУслугТовары.Ссылка
ИЗ
    Документ.ПоступлениеТоваровУслуг.Товары КАК ПоступлениеТоваровУслугТовары
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
            Номенклатура.Ссылка КАК Ссылка
        ИЗ
            Справочник.Номенклатура КАК Номенклатура
        ГДЕ
            Номенклатура.Наименование ПОДОБНО "%а%"
            )
             КАК ВложенныйЗапрос
        ПО ПоступлениеТоваровУслугТовары.Номенклатура = ВложенныйЗапрос.Ссылка

план ms sql:
Rows         Executes     StmtText                                                                                                                                                                                                                                                                                 StmtId       NodeId       Parent       PhysicalOp           LogicalOp            Argument                                                                                                                                                                                                                                                           DefinedValues                                                                                     EstimateRows EstimateIO   EstimateCPU  AvgRowSize   TotalSubtreeCost OutputList                                       Warnings     Type         Parallel     EstimateExecutions
----         --------     --------                                                                                                                                                                                                                                                                                 ------       ------       ------       ----------           ---------            --------                                                                                                                                                                                                                                                           -------------                                                                                     ------------ ----------   -----------  ----------   ---------------- ----------                                       --------     ----         --------     ------------------
25765        1            Hash Match(Inner Join, HASH:([T3].[_IDRRef])=([T1].[_Fld12461RRef]), RESIDUAL:([aerofood].[dbo].[_Reference144].[_IDRRef] as [T3].[_IDRRef]=[aerofood].[dbo].[_Document468_VT12459].[_Fld12461RRef] as [T1].[_Fld12461RRef]))                                                            0            0                         Hash Match           Inner Join           HASH:([T3].[_IDRRef])=([T1].[_Fld12461RRef]), RESIDUAL:([aerofood].[dbo].[_Reference144].[_IDRRef] as [T3].[_IDRRef]=[aerofood].[dbo].[_Document468_VT12459].[_Fld12461RRef] as [T1].[_Fld12461RRef])                                                                                                                                                                36995,1      0            0,621689     23           1,95204          [T1].[_Document468_IDRRef]                                    PLAN_ROW     0            1                  
14842        1              |--Nested Loops(Inner Join, OUTER REFERENCES:([Expr1007], [Expr1008], [Expr1009]))                                                                                                                                                                                                     0            1            0            Nested Loops         Inner Join           OUTER REFERENCES:([Expr1007], [Expr1008], [Expr1009])                                                                                                                                                                                                                                                                                                                14601,9      0,111273     0,0162191    81           0,127492         [T3].[_IDRRef]                                                PLAN_ROW     0            1                  
0            0              |    |--Compute Scalar(DEFINE:([Expr1007]=LikeRangeStart([@P1]), [Expr1008]=LikeRangeEnd([@P1]), [Expr1009]=LikeRangeInfo([@P1])))                                                                                                                                                     0            2            1            Compute Scalar       Compute Scalar       DEFINE:([Expr1007]=LikeRangeStart([@P1]), [Expr1008]=LikeRangeEnd([@P1]), [Expr1009]=LikeRangeInfo([@P1]))                                                                                                                                                         [Expr1007]=LikeRangeStart([@P1]), [Expr1008]=LikeRangeEnd([@P1]), [Expr1009]=LikeRangeInfo([@P1]) 1            0            0            8017         0                [Expr1007], [Expr1008], [Expr1009]                            PLAN_ROW     0            1                  
1            1              |    |    |--Constant Scan                                                                                                                                                                                                                                                             0            3            2            Constant Scan        Constant Scan                                                                                                                                                                                                                                                                                                                                                                             1            0            0            0            0                                                                              PLAN_ROW     0            1                  
14842        1              |    |--Index Seek(OBJECT:([aerofood].[dbo].[_Reference144].[_Referen144_Descr_SR] AS [T3]), SEEK:([T3].[_Description] > [Expr1007] AND [T3].[_Description] < [Expr1008]),  WHERE:([aerofood].[dbo].[_Reference144].[_Description] as [T3].[_Description] like [@P1]) ORDERED FORWARD) 0            11           1            Index Seek           Index Seek           OBJECT:([aerofood].[dbo].[_Reference144].[_Referen144_Descr_SR] AS [T3]), SEEK:([T3].[_Description] > [Expr1007] AND [T3].[_Description] < [Expr1008]),  WHERE:([aerofood].[dbo].[_Reference144].[_Description] as [T3].[_Description] like [@P1]) ORDERED FORWARD [T3].[_IDRRef]                                                                                    14601,9      0,111273     0,0162191    81           0,127492         [T3].[_IDRRef]                                                PLAN_ROW     0            1                  
37092        1              |--Clustered Index Scan(OBJECT:([aerofood].[dbo].[_Document468_VT12459].[_Documen468_VT12459_IntKeyInd] AS [T1]))                                                                                                                                                                      0            12           0            Clustered Index Scan Clustered Index Scan OBJECT:([aerofood].[dbo].[_Document468_VT12459].[_Documen468_VT12459_IntKeyInd] AS [T1])                                                                                                                                                                           [T1].[_Document468_IDRRef], [T1].[_Fld12461RRef]                                                  37092        1,14905      0,0409582    39           1,19001          [T1].[_Document468_IDRRef], [T1].[_Fld12461RRef]              PLAN_ROW     0            1

Вот пример, что PG выбирает хэш, если есть статистика по таблице из подзапроса:

ВЫБРАТЬ
    док.Ссылка КАК Ссылка
ИЗ
    Документ.умпЗапросНаПеревозку КАК док
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
            контрагенты.Ссылка КАК Ссылка
        ИЗ
            Справочник.Контрагенты КАК контрагенты) КАК вложенныйзапрос
        ПО док.Контрагент = вложенныйзапрос.Ссылка

hash join  (cost=699.60..4148.76 rows=23972 width=20) (actual time=2.408..17.088 rows=23967 loops=1)
  hash cond: (t1.Контрагент = t3.Ссылка)
  ->  seq scan on Документ.умпЗапросНаПеревозку t1  (cost=0.00..2969.72 rows=23972 width=40) (actual time=0.003..4.153 rows=23972 loops=1)
  ->  hash  (cost=628.71..628.71 rows=5671 width=20) (actual time=2.397..2.397 rows=5671 loops=1)
        buckets: 1024  batches: 1  memory usage: 272kb
        ->  seq scan on Справочник.Контрагенты t3  (cost=0.00..628.71 rows=5671 width=20) (actual time=0.002..1.282 rows=5671 loops=1)
total runtime: 18.460 ms

(20) В том то и дело, что если по твоей ссылке в гугле включить отбор только за последний год, то про nested loops там будет всего пару тем, основные темы про косяк с нестедлупсом датируются 2012 годом. За пару лет могли уже и залатать.

(25) я вот ошибся кстати, тут ms sql тоже хэш использует, т.к. умело предположил, что на выходе будет около 14к строк.
Но в (26) видно, что pg также действует.
Но если в подзапросе посодеинять таблицы непредсказуемо - оба выдают nested loops

(28) Всё-таки, по моему опыту, у mssql оптимизатор намного умнее и ошибка с нестедлупом для него нехарактерна и достаточно редка.. а вот постгрес очень любит такие методы.