Это удивительно, поскольку запросы на чтение никогда не блокируются ничем, кроме блокировки ACCESS EXCLUSIVE
, который требуется для таких операций, как DROP TABLE
, TRUNCATE
, ALTER TABLE
и аналогичных операторов.
Возможно,блокировки - это «легкие блокировки» во внутренних структурах данных PostgreSQL, которые обычно хранятся очень короткое время. Я не знаю, что в запросе PostGIS могло вызывать высокую конкуренцию при таких внутренних блокировках, но тогда вы не показали оператор или план его выполнения, а также не указали точные события блокировки.
Если выу меня есть несколько одновременных запросов, каждый из которых занимает много времени, например, 500 мс, определенно должен выполняться параллельно.
Помимо возможностей некоторой внутренней конкуренции за блокировку, я могу придумать два объяснения:
Большинство запросов достаточно коротки, чтобы одного ядра было достаточно для обработки всех запросов. Каждое соединение тратит большую часть своего времени на ожидание клиента.
Система привязана к вводу / выводу, так что большинство процессоров просто трясут. Это указывалось бы в процентах по iowait ЦП от 10 и более.