15.06.2022 05:02
polin11
 
Использую PGSQL.
Есть таблица записей ~ 1000 000 записей
SQL код:
CRE ATE   TABLE forms (
    
id serial PRIMARY KEY,
    
account INT NOT NULL,
    
author text,
    
salary INT NOT NULL
);
INS ERT INTO  forms(accountauthorsalaryVALUES 
(1100889'Иванов'30),
(
1100889'Петров'40),
(
4443'Сидоров'40),
(
1100889'Сергеев'50
При авторизации пользователя в аккаунт идет пересчет поля salary в целом по аккаунту для всех пользователей
SQL код:
UPDATE forms
SET salary 
= (SEL ECT....)
WHERE account 1100889 
Перед обновление делаю блокировку по аккаунту с таймаутом 5 секунд.

SQL код:
BEGIN ISOLATION LEVEL READ COMMITTED READ WRITE;
SE T LOCAL statement_timeout '5000ms'
SELECT PG_ADVISORY_XACT_LOCK("lock_id"FR OM (
                
SELECT UNNEST('{1100889}'::BIGINT[]) AS "lock_id"
            
LocksId      
RESET statement_timeout 
В процессе обновления могут выполнятся обновления по конкретному сотруднику из этого аккаунта, я также ставлю
блокировку по аккаунту.
SQL код:
UPDATE forms
SE T salary 
100
WHERE account 
1100889 AND author 'Иванов' 
Когда общий запрос обновления по аккаунту (большой аккаунт) выполняется долго > 5 секунд,
то падает ошибка на второй запрос обновления
по сотруднику ошибка canceling statement due to statement timeout.
Понятно, что оптимальное решение ускорить запрос расчета целиком по аккаунту.

Плохо разбираюсь в тебе блокировок в PGSQL, просьба подсказать как исправить ситуацию с точки зрения
блокировок, в какую сторону смотреть?
15.06.2022 07:35
OlegON
 
не очень понятно, что именно ты собираешься исправлять и откуда взялась цифра в 5 секунд?
индексы на forms есть?
ты задаёшь таймаут и не хочешь, чтобы по таймауту отваливалось?
15.06.2022 12:41
polin11
 
Самое логичное это ускорить запрос для обновления в целом по аккаунту, чтобы выполнялся за 5 секунд - это понятно.
Тут вопрос в другом может вообще отказаться от блокировок.
Хочу узнать\почитать про другой механизм, при помощи которого можно разрулить этот алгоритм.
Может использовать что-то типа SELECT ... FOR UPDATE, ordered UPDATE, SKIP LOCKED?
Часовой пояс GMT +3, время: 21:02.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.