Я тут нарвался на LWLock:LockManager после переезда на partitioned table

Question

Я тут нарвался на LWLock:LockManager после переезда на partitioned table

(32 HASH партиции) он же fastpath в pg_locks и у меня вопрос:

Insert on conflict update в partitioned таблицу сколько локов возьмёт если был конфликт и update HOT? Один на таблицу, один на индекс для on conflict минимум, но эти локи на партицию куда пишет или на все партиции просто потому что они есть в плане? PostgreSQL 15.2

#backend #devops #pgsql #programming #russian

0

01.08.2023

4 ответов

21 просмотр

Mike Wazowski Автор вопроса

Максим Логвиненко
Если не ошибаюсь, то на все объекты, которые есть ...

Тоже читал эту доку и просто шикарный summary от gitlab https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/2301 (у них PG12 многое могло поменяться). Но вот не понятно с execution time partition prunning: если заход в индекс есть в плане, во время выполнения он туда не факт что зайдет , значит , наверное, никаких локов брать не будет, но как оно на самом деле я хз.

0

01.08.2023

Максим Логвиненко

Mike Wazowski
Тоже читал эту доку и просто шикарный summary от ...

а pg_locks что показывает? сделал простой запрос к партиционированной таблице по дате с обращением к последней партиции и посмотрел блокировки: блокировка на саму таблицу, на каждую партицию таблицы и на каждую партицию индекса, в сумме 1к+ блокировок, все AccessShareLock, первые 16 из них - fastpath

0

01.08.2023

Mike Wazowski Автор вопроса

Максим Логвиненко
а pg_locks что показывает? сделал простой запрос к...

Спасибо за подсказку, поэксперементировал, всё оказалось ещё интереснее. В реальном приложении используются prepared statements и тут начинает играть plan_cache_mode: - generic: lock на каждую партицию и на 1 индекс в этой партиции нужный для запроса - custom: все партиции и все индексы. Это потому что они нужны для планирования, которое случается при каждом execute

0

01.08.2023

Максим Логвиненко · Accepted Answer

Если не ошибаюсь, то на все объекты, которые есть в плане будет наложен как минимум access share, т.е. на каждую партицию таблицы и на каждую партицию индекса. Сегодня как раз читал доку по Авроре на aws, в ней говорится, что при превышении лимита FP_LOCK_SLOTS_PER_BACKEND аврора переходит на небыстрые блокировки. Думаю в ванильном пг примерно похожая ситуация, надеюсь более опытные коллеги поправят. Сама дока: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.lw-lock-manager.html

172 похожих чатов

Я тут нарвался на LWLock:LockManager после переезда на partitioned table

4 ответов

Похожие вопросы