Случайно обнаружено на просторах бета 10го постреса от postgrespro ! Особенно интересно тем кто пользует DW на 1C http://repo.postgrespro.ru/1c-10-beta/
Теперь и параллельный скан индексов и нативное партиционирование !

(0)"нативное партиционирование" Своими словами сможешь?

Доки : https://postgrespro.ru/docs/postgrespro/10/ddl-partitioning

Смысл в том, если большая таблица(например 100Гб и больше) в которой лежит аналитика с периодичностью, можно ее "разделить" например по месяцам и при последовательном чтении планировщик будет перебирать данные только из файлов этой "секции" а не всей таблицы.

(1) видимо партишент тэйбл. Оракл это умел начиная с 8ЕЕ

Partitioning refers to splitting what is logically one large table into smaller physical pieces. Partitioning can provide several benefits:

    Query performance can be improved dramatically in certain situations, particularly when most of the heavily accessed rows of the table are in a single partition or a small number of partitions. The partitioning substitutes for leading columns of indexes, reducing index size and making it more likely that the heavily-used parts of the indexes fit in memory.

    When queries or updates access a large percentage of a single partition, performance can be improved by taking advantage of sequential scan of that partition instead of using an index and random access reads scattered across the whole table.

    Bulk loads and deletes can be accomplished by adding or removing partitions, if that requirement is planned into the partitioning design. Doing ALTER TABLE DETACH PARTITION or dropping an individual partition using DROP TABLE is far faster than a bulk operation. These commands also entirely avoid the VACUUM overhead caused by a bulk DELETE.

    Seldom-used data can be migrated to cheaper and slower storage media.

(2) во всех системах это есть, но практически никто не использует

(2) а после рестуктуризации 1С это партиционирование сохранится?

(5) olap-системы практически все используют

хз, надо смотреть и тестить официально пока нигде не заявлена поддержка 10й версии

Подниму на тестовом серваке, погоняю, через пару часов станет ясно что и как

(7) олап системы на 1с? это где такие?

(6) хороший вопрос, пока 1С это не поддерживает нативно партишен тэйбл - использование этого его это нарушение лицензинного соглашения. А вот распараллеленный скан ничего не нарушает.

(10) ну типа агрегаты под это и задумывались

да, но агрегаты это тот еще гемор ) пользовали

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

(12) я про теорию знаю. Я спрашивал где они все?

(15) там же, где бизнес процессы

Сервер PostgreSQL 10 нормально поднялся на Centos 7, в изначальном конфиге отсутствовали настройки plantuner и online_analyze, по какой-то причине теперь постргря лежит в /opt. 1С скушало 10ую версию без проблем, ИБ открывается. Если будет время - в течении дня замерю время исполнения большого аналитического отчета на 9.6.8 и на 10.4 при одинаковых настройках

(5) ты тупой? сам же пишешь - "во всех системах", а потом перескочил на 1С

(17) будь добр, очень интересно взглянуть

(17) очень круто! еще вот это запусти, если будет время: http://catalog.mista.ru/public/173394/

(20) ок, думаю ближе к вечеру или завтра с утра поделюсь результатми

(18) во всех других бд, которые для 1с

Выполнил,
9.6.8 - http://rgho.st/8qNjbTSBg
10.4 - http://rgho.st/7jb5S99mP

OS: Centos 7 3.10.0-862.2.3.el7.x86_64
FS: ZFS (recordsize 128K, compression lz4, atime off, logbias throughput)

PostgreSQL.conf:

max_connections = 128
shared_buffers = 1GB
temp_buffers = 256MB
work_mem = 512MB
maintenance_work_mem = 256MB
max_worker_processes = 8
max_parallel_workers_per_gather = 4
synchronous_commit = off
full_page_writes = off
random_page_cost = 1.5
parallel_tuple_cost = 0.02
effective_cache_size = 10GB
max_locks_per_transaction = 150

online_analyze.threshold = 50
online_analyze.scale_factor = 0.1
online_analyze.enable = on
online_analyze.verbose = off
online_analyze.min_interval = 10000
online_analyze.table_type = 'temporary'
plantuner.fix_empty_table = false

Чето не радуют графики

Как есть, может beta...

Я больше ожидаю разницу при выборке данных с больших таблиц с большими индексами, будет время сегодня погоняю, выложу сравнение

Может zfs привносить свое влияние. Читал что для постгресс, лучше файловую систему ext3, как понял маленькая нагрузка на ЦП и выигрыш при больших количествах файлов.

(27) будет время разверну на xfs и ext4 - запущу повторно

а зачем компрессию на файловой системе? не уж то такая большая база?

(29) 4Tb

(30) реструктуризацию как делаете ?. сколько пользователей?

(30) а конфа какая?

Неужели решили поддержать секционирование в платформе? Что-то я сомневаюсь. Если решат, то как минимум скуль тоже поддержат. И интерфейс для администрирования должен появиться. И в Зазеркалье похвалятся обязательно. Пока ничего такого не видно.

А было бы круто, конечно.

(33) С какого вы сделали вывод о поддержке секционирования в 1с?

(31) (32) конфигурация самописная, основой объем в регистрах накопления, они изначально спроектированы весьма удачно, за 4е года пришлось сделать только одну реструктуризацию. Остальное маленькое и реструктуризация проходит быстро. Пользователей мало от 4 до 15, но оч.большая отчетность, база имеет смысл ETL + DW + ROLAP.

что такого можно спроектировать "очень удачно" в регистрах накопления...

по гилеву между 9.6 и 10 разница на уровне погрешности.
возможно с большими базами и будут преимущества, но пока смысла связывать с бетой не вижу.
Тестил под линукс на xfs

(20) Нет там существенной разницы
PostgreSQL 9.6.7-1C - http://fragster.ru/perfomanceTest/result.php?guid=b2ca18be-5ee0-11e8-5e88-b06ebf2ee3f0
Postgres Pro 1C 10.4(beta) - http://fragster.ru/perfomanceTest/result.php?guid=041a4616-5ed8-11e8-9984-b06ebf2ee3f0
10.4 чуть шустрее будет, процентов на 10(кроме временных таблиц). Результаты теста Гилева практически одинаковые, 69-70.

(38) ИМХО 10% практически забесплатно - неплохой профит

а вот -10% во временных таблицах непонятно, в релиз нотесах вроде писали про их оптимизацию

Тем временем, Postgre выпустил 11-ю бету. С хэш-секционированием и прочими плюшками.

(39)Сделал чуть получше и на 9.6.7 и на 10.4
http://fragster.ru/perfomanceTest/result.php?guid=dedafd10-5f85-11e8-d38d-b06ebf2ee3f0
http://fragster.ru/perfomanceTest/result.php?guid=3f396d6a-5f6b-11e8-ad8a-b06ebf2ee3f0
Выключил spectre_v2 при загрузке ядра(nopti уже был).

(42) и еще + 10% (хоть их у нас раньше и отняли просто)

Инмемори там нет....

(11) >>>это нарушение лицензионного соглашения
этот пункт соглашения достаточно противоречивый на самом деле

т.к. база данных MS SQL является частью ПО MS SQL, значит лицензии 1С на него распространяться не могут. (ну и постгре аналогично)

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

Рабочая версия PostgreSQL 10.3-2.1C выпущена, но использовате ее рекомендовано с версии 1С 8.3.13.

http://fragster.ru/perfomanceTest/result.php?guid=f7381b6a-6a2d-11e8-6581-b06ebf2ee3f0
Результат по временным таблицам  у PostgreSQL 10.3-2.1C чуть лучше, чем для Postgres Pro 1C 10.4(beta), хотя, может и платформа 8.3.13 что-то привносит. Если выполнять только тест временных таблиц в одном потоке, получается 26000. Результаты остальных тестов в пределах 1%.

(0) Они еще баг с Cross Join в последней версии не поправили. Пришлось конфы немножко править. Хотя за само использование его я бы сильно бил по рукам.

Около 2-х лет сидим плотненько на сборках от PostgresPro. Они побыстрее "1С-ных", при должной настройке.  

(2) Делали такое лет 5 назад. Слетало на любой чих. Реструктуризация/обновление сначала создает "Таблица"NG и туда впихивает данные. Так что любое деление по дате - отваливается сразу.

(17)  На centos она вроде всегда туда ставилась.


(46) 1С наконец избавилась от патчей для слона и польностью перешла на расширения. Теперь не нужно добавлять репозиторий от Postgrespro. В 3.13 столько всего хорошего и долгожданного заявлено, что явно будет товарный поезд багов.  


(39) Гилевские попугаи многое не учитывают. В реальной работе прирост должен быть сильнее.

(11) Что вы все уперлись в это лицензионное соглашение? Что вам 1С сделает, если в таблицы СУБД залезете? Отругает? По попе отшлепает? Может хватит уже...

(49) Так никто его не читал, но все точно знают.

(49) +1
тем более это незаконный пункт, база данных - отдельный продукт, что хотим то с ним и делаем

у других вендоров тоже есть этот пункт, но он влияет только на поддержку, не лезешь в ядро - получаешь поддержку (за деньги), лезешь - сам копайся (даже если за деньги)

Народ, никто не подскажет что это такое было, когда поставил предыдущий релиз 9.6.7-1.1C на 8.3.11.2867 и словил отсутствие сортировки по наименованию в движениях и печатный форме?
Так и не понял как победить. В MS SQL Таких проблем не было, а тут даже непонятно по какому принципу - в документе одно, а при печати какой-то случайный порядок позиций.
Или Postgre не умеет сразу из коробки нормально работать, надо все допиливать?

>в документе одно, а при печати какой-то случайный порядок позиций.

Это ты сам виноват, если пользовался запросом и не указывал порядок сортировки. А с мсскулем тебе просто везло.

вот если обход в объектной методике выдавал строки не в том порядке - тогда косяк. только ведь такого не было, да?

(54) Вообще-то речь про свежую типовую УТ 11.4.
И по-умолчанию сортировка должна быть по номеру строки хотя бы, или запрос возвращает тот же порядок как в ТЧ документа, а там получался случайный разброс. Удивило то, что никогда ничего такого не встречал на MS, а тут сразу грабли какие-то.

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

Значит в 1С такие же писатели, сидят на MS SQL и не подозревают о неадекватном подведении типовых на Postgre.

Насколько помню в MSSQL и PostgreSQL был разный порядок сортировки и как раз этот момент был учтен в однм из патчей PostgreSQL для 1с. Может с патчем что-то накосячили?

(57) нет, тот порядок сортировки связан со значением NULL

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

Больше версий PostgreSQL Pro отдельно под 1С больше не существует? Теперь все патчи присутсвуют в самой PostgreSQL Pro?

А вижу - "Доработки, реализуемые фирмой «1С» для СУБД PostgreSQL, реализованы в виде расширения." Тем самым - версия 8.3.13 теперь обязательна.