Об этом надо спросить авторов документа, а не обсуждаемой статьи. Спрашивайте.
поскольку это рекомендации, а не правила, «и т.п.» вполне допустимо, хоть и не однозначно.
Идеи мне неизвестны. Если речь об обсуждаемом документе ЦКИТ, правильнее спросить об этом у его авторов. Morigh, что они ответили?
Мое субъективное мнение — речь об ограничении наклеивания шильдиков.
Но это методические рекомендации, а не правила Реестра.
Заранее трудно сказать, будет ли вариант с JSON быстрее. В простейших случаях -нет, т.к. JSON надо дополнительно парсить, чтобы извлечь значения полей (даже JSONb, хоть он и читается гораздо быстрее). Если поиск по индексу по конкретному набору полей внутри JSON, то надо строить функциональный BTree-индекс по этим полям, скорость работы будет примерно такая же.
JSON делали не для скорости, а для функциональности. Например, в нем можно иметь многоуровневую структуру данных внутри одного поля, а в «плоской» таблице как это сделать? В отдельных случаях JSON ускоряет, если, например, позволяет сократить объем данных, или запихнуть несколько таблиц в одну.
Индекс не очень-то приспособлен для таких вещей. Вот например, размер записи в btree ограничен тем, что на странице индекса их должно минимум три умещаться. Большие поля не пройдут, а toast в индексе нет.
Дело не в сложных транзакциях.
Вот тут все есть, postgrespro.ru/docs/postgresql/10/logical-replication-restrictions.html
DDL логической репликацией не поддерживается, соответственно надо менять схему данных руками на мастере и реплике.
Также надо учесть, что не переносятся последовательности (значит, руками на реплике нужно открутить их вперёд с запасом)
Не переносятся также секционированные таблицы и блобы.
Мы говорим так. Но это спорное название, т.к. понятие «покрывающий индекс» определено по отношению к конкретному запросу. По сути, это индекс, которого достаточно для index-only scan в этом запросе. Не обязательно с INCLUDE. См use-the-index-luke.com/sql/clustering/index-only-scan-covering-index
Это можно делать с помощью логической репликации. Начиная с PostgreSQL 9.4 (там логическая репликация реализована в расширении pglogical ).
А начиная с 10-й версии она есть уже в самом постгресе, и настраивается очень легко. Главное, осторожнее с DDL в переходный период!
Интересный материал, спасибо. Попробуем что-нибудь собрать. А пока посмотрите вот на эту таблицу сравнения sql-workbench.net/dbms_comparison.html — никакого холивара, только факты.
Да, указанная проблема действительно есть! Однако из этого не следует, что индекс не будет использован. А если он будет использован, он может сильно помочь.
Если речь о Standard, то продается он по цене техподдержки за один год. Вместе с ним получаете техподдержку. И почитайте лицензию, там не упомянута возможность бесплатного использования в коммерческих целях.
поскольку это рекомендации, а не правила, «и т.п.» вполне допустимо, хоть и не однозначно.
Мое субъективное мнение — речь об ограничении наклеивания шильдиков.
Но это методические рекомендации, а не правила Реестра.
JSON делали не для скорости, а для функциональности. Например, в нем можно иметь многоуровневую структуру данных внутри одного поля, а в «плоской» таблице как это сделать? В отдельных случаях JSON ускоряет, если, например, позволяет сократить объем данных, или запихнуть несколько таблиц в одну.
Это непонятно. Как именно определяется язык? python и JS тоже правильно подсвечиваются?
Вот тут все есть, postgrespro.ru/docs/postgresql/10/logical-replication-restrictions.html
DDL логической репликацией не поддерживается, соответственно надо менять схему данных руками на мастере и реплике.
Также надо учесть, что не переносятся последовательности (значит, руками на реплике нужно открутить их вперёд с запасом)
Не переносятся также секционированные таблицы и блобы.
А начиная с 10-й версии она есть уже в самом постгресе, и настраивается очень легко. Главное, осторожнее с DDL в переходный период!