История изменений

наверное у ваших знакомых интернет отключен и они так и не смогли узнать, что PostgreSQL - это база, предназначенная сугубо для запуска на лаптопе.

ладно, будем считать что перепись экспертов по PostgreSQL закончилась успешно, а теперь воспользуется силой интернета…

идем по ссылке: https://postgrespro.ru/list/thread-id/2500195 и читаем информацию, можно сказать из первых рук (замечу, что «скандал» с Uber был в 2016, за 4 года до переписки, что я привожу в пример):

It’s a pity, because such attention is one of the reasons why Postgres is pgbench-oriented database showing good results at notebooks but not at real systems running at power servers (NUMA, SSD, huge amount of memory, large number of cores,…).

Unfortunately we have not to wait for decade or two. Postgres is faced with multiple problems at existed multiprocessor systems (64, 96,.. cores). And it is not even necessary to initiate thousands of connections: just enough to load all this cores and let them compete for some resource (LW-lock, buffer,…). Even standard pgbench/YCSB benchmarks with zipfian distribution may illustrate this problems.

There were many proposed patches which help to improve this situation. But as far as this patches increase performance only at huge servers with large number of cores and show almost no improvement (or even some degradation) at standard 4-cores desktops, almost none of them were committed. Consequently our customers have a lot of troubles trying to replace Oracle with Postgres and provide the same performance at same (quite good and expensive) hardware.

Certainly, both we and customer has made workload analysis & optimization. It is not a problem of particular queries, bad plans, resource exhaustion,…

Unfortunately there many scenarios when Postgres demonstrates not gradual degrade of performance with increasing workload, but «snow avalanche» whennegative feedback cause very fastparalysis of the system.

This case is just one if this scenarios. It is hard to say for sure what triggers the avalanche… Long living transaction, huge number of tables, aggressive autovacuum settings… But there is cascade of negative events which cause system which normally function for months to stop working at all.

наверное у ваших знакомых интернет отключен и они так и не смогли узнать, что PostgreSQL - это база, предназначенная сугубо для запуска на лаптопе.

ладно, будем считать что перепись экспертов по PostgreSQL закончилась успешно, а теперь воспользуется силой интернета…

идем по ссылке: https://postgrespro.ru/list/thread-id/2500195 и читаем информацию, можно сказать из первых рук (замечу, что «скандал» с Uber был в 2016, за 4 года до переписки, что я привожу в пример):

It’s a pity, because such attention is one of the reasons why Postgres is pgbench-oriented database showing good results at notebooks but not at real systems running at power servers (NUMA, SSD, huge amount of memory, large number of cores,…).

Unfortunately we have not to wait for decade or two. Postgres is faced with multiple problems at existed multiprocessor systems (64, 96,.. cores). And it is not even necessary to initiate thousands of connections: just enough to load all this cores and let them compete for some resource (LW-lock, buffer,…). Even standard pgbench/YCSB benchmarks with zipfian distribution may illustrate this problems.

There were many proposed patches which help to improve this situation. But as far as this patches increase performance only at huge servers with large number of cores and show almost no improvement (or even some degradation) at standard 4-cores desktops, almost none of them were committed. Consequently our customers have a lot of troubles trying to replace Oracle with Postgres and provide the same performance at same (quite good and expensive) hardware.