> Позволяет оперативно и без влияния на существующую структуру объектов принудительно определять план выполнения SQL запроса, выполняемого как самостоятельный запрос, подготовленный запрос или запрос в составе PL/pgSQL-блока.
Речь идёт про хинты оптимизатора?
> А также без изменения текста запроса на стороне приложения корректировать план выполнения запроса на лету, на стороне сервера при его обработке.
Вы реализовали адаптивное исполение запроса, т.е. динамическую смену плана(подплана) в зависимости от онлайн статистики?
Но если мы говорим про интерактивные транзакции, то есть отдельный MVCC движок. Он позволяет выполнять в режиме serializable уже интерактивные транзакции, но придётся дополнительно обрабатывать потенциальные конфликты транзакций.
Можно подробнее расписать этот тезис:
что подразумевается под «интерактивностью» транзакций?
как реализовано версионирование таплов в рамках MVCC движка?
как происходит обработка конфликтов — вручную, отдельной логикой после процессинга транзакции?
В обычных реляционных базах таблица в памяти — это не персистентное хранилище, используемое для каких-то быстрых операций.
Разве эти инструменты позволяют из коробки читать с Slave даже? Даже если и использовать, то в них нужно писать отдельную логику чтобы публиковать IP Slave
Для только чтения будет отдельный эндпоинт. Это надо учитывать в приложении. Никакого разбора запроса на предмет read-only в промежуточных слоях не будет.
Можно, но в этом случае транзакция на запись в основную таблицу и изменение в стороннюю очередь будет распределённой. Использование внутренних очередей позволит обеспечить атомарность таких операций достаточно низкой ценой
1. У вас здесь налицо искажение cardinality для index scan'ов по (с) и (a, b) на целый порядок — 150331 против 3982643! и 1258378 против 377222. Поэтому имхо лучше начать атаковать эту проблему. Например, если вы делали vacuum full — analyze, увеличитьте выборку по a,b,c при сборе статистики ALTER TABLE SET STATISTICS. Более подробно про оценку кардинальности можно почитать в доке www.postgresql.org/docs/9.5/static/planner-stats-details.html.
2. При построении составного индекса первый параметр должен быть наиболее селективным в запросах среди остальных. У вас планер таковым считает c (150331 строк против 1258378 для (a, b) от общего числа в table1), поэтому и отказывается использовать индекс по (a,b,c). Это необходимо править через более тщательный сбор статистики.
> Позволяет оперативно и без влияния на существующую структуру объектов принудительно определять план выполнения SQL запроса, выполняемого как самостоятельный запрос, подготовленный запрос или запрос в составе PL/pgSQL-блока.
Речь идёт про хинты оптимизатора?
> А также без изменения текста запроса на стороне приложения корректировать план выполнения запроса на лету, на стороне сервера при его обработке.
Вы реализовали адаптивное исполение запроса, т.е. динамическую смену плана(подплана) в зависимости от онлайн статистики?
Можно подробнее расписать этот тезис:
Очень спорное суждение. Поясните его, пожалуйста.
Можно воспользоваться калькулятором первичных настроек
Для только чтения будет отдельный эндпоинт. Это надо учитывать в приложении. Никакого разбора запроса на предмет read-only в промежуточных слоях не будет.
2. При построении составного индекса первый параметр должен быть наиболее селективным в запросах среди остальных. У вас планер таковым считает c (150331 строк против 1258378 для (a, b) от общего числа в table1), поэтому и отказывается использовать индекс по (a,b,c). Это необходимо править через более тщательный сбор статистики.