Потому что соотношение чтения к записи не делают по числу запросов. Знаете ли, select одной строки по первичному ключу и половины таблицы seqscan'ом - это всё ещё один запрос с кардинально разными затратами io.
А с переносом части чтения на реплики - берёте topN отчёт и так и говорите:
ребята, смотрите: у нас дофига нагрузки вот от этих пары oltp запросов. Они же вроде не критичны к мелкому лагу? Давайте их на реплику скинем.
А вот этот милый запрос на 20% суточной нагрузки - это же вообще аналитика за прошлые сутки для менеджеров, давайте на аналитическую slow реплику перенесём, нафиг оно нам на мастере автовакууму мешает
Бессмысленная метрика. Нет, отдельных счётчиков нет.
Осмысленная метрика - сколько таплов читали-писали: n_tup_ins/n_tup_upd/n_tup_del/n_tup_hot_upd/seq_tup_read/idx_tup_fetch в pg_stat_all_tables.
И другая осмысленная метрика - topN запросов по времени выполнения из pg_stat_statements.
Если вы коммитили каждую запись отдельно, да ещё на дефолтном конфиге - могло было быть и хуже чем ~33 tps.
Если прочитать bulk insert раздел - то будет совсем другой результат.
(1,60) зависит от strict sql_mode
(2,5) у меня на 5.5 работает, может запретили в 5.7 (хотя буду удивлён).
Если вам не кажется странным - то используйте. Я бы предпочёл не исследовать удивительные фокусы типизации enum и его взаимодействия с и без того мягкой типизации mysql.
Жаль что в mysql check constraint нет - вот это было бы реальное решение задачи без странных фокусов.
Нормальная форма - это термин теории реляционных баз данных.
Т.е. сначала свои данные приводите к нормальной форме. Если это будет давать проблемы - тогда отходите от нормальной формы (т.е. денормализуете данные)
Медлителен потому что такая гора кода в принципе не может быть эффективна по производительности рантайма в условиях shared nothing архитектуры PHP "обработал запрос и умер". Симфони берут не ради производительности.
Бороться соответственно выкидывая всё лишнее из мест, критичных к скорости ответа.
Просто возьмите профилировщик, и посмотрите, сколько времени что занимает.
Есть в коробке у дебиана sudo или нет - зависит от ответов на вопросы установщика. Если задать root пароль - возможно sudo не будет (не помню), если не задавать - будет настроен sudo для следом создаваемого пользователя.
Я бы даже слово добавил: блокировки снимутся только после окончания транзакции.
Вернуть блокировку до окончания транзакции невозможно (кроме некоторых нетранзакционных блокировок).
При обрыве соединения будет сделан rollback - ведь commit не сказали, база не может знать завершена ли транзакция и потому единственный вариант - откатывать. Но про клиента ремарка хорошая, неизвестно, вдруг клиент как раз перед отключением вызывает неяный commit.
Во-первых - зачем? Это бесполезное справочное поле.
Во-вторых - никак. Не, по идее SPD это EEPROM и при большом желании можно перепрограммировать, но DDR3 2400мгц в JEDEC вообще никак не стандартизирован. Да и нестандартное напряжение в JEDEC части SPD не указать, только в XMP расширении.
Отличия нет. База к которой fdw подключается вообще ничего не знает о fdw, для неё это рядовой libpq клиент. Любой запрос к любой таблице хватает как минимум ACCESS SHARE на эту таблицу. И даже ACCESS SHARE конфликтует с ACCESS EXCLUSIVE, который требуют drop, vacuum full, reindex и многие виды alter table.
Смотреть, как уже сказал, в pg_stat_activity на предмет долгих транзакций. Ну или, если хотите, можете поискать в pg_locks, pid'ы удерживающих блокировки транзакций там тоже будут.
fdw никаких локов не держит от одного своего существования на другом сервере. Транзакции через него проходящие на этот кластер - разумеется держат.
Найти где находится pg_database в системном каталоге, его oid где-то в исходниках жёстко прописан. Затем прочитать pg_database и найти oid нужной базы - это и будет путь
которые, кстати, проходят напрямую, без транзакций
Если вы не делаете begin & commit - это не значит, что у вас нет транзакций.
fdw с точки зрения удалённого сервера ничем не отличается от других клиентов, рядовой libpq клиент. Две программы для возвращения места ФС я указал, на очень многих базах проверены.
за "всегда" ответить не могу, не сетевой администратор. Но ожидать подключения по ipv6 в 2018 году вполне логично и в hba пишутся 3 способа обращения для локальной машины.
А с переносом части чтения на реплики - берёте topN отчёт и так и говорите: