Re: query against pg_locks leads to large memory alloc
От | Dave Owens |
---|---|
Тема | Re: query against pg_locks leads to large memory alloc |
Дата | |
Msg-id | CA+OQrzg0OwnU4TyMnwi577M7aCrNjBb0ObJoyZW+ndUWjmOEgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: query against pg_locks leads to large memory alloc (Kevin Grittner <kgrittn@ymail.com>) |
Ответы |
Re: query against pg_locks leads to large memory alloc
|
Список | pgsql-performance |
I now have 8 hours worth of snapshots from pg_stat_activity and pg_locks (16 snapshots from each table/view). I have turned off collection at this point, but I am still able to query pg_locks: # SELECT mode, count(mode) AS count FROM pg_locks GROUP BY mode ORDER BY mode; mode | count ------------------+--------- AccessShareLock | 291 ExclusiveLock | 19 RowExclusiveLock | 4 RowShareLock | 1 SIReadLock | 7287531 (5 rows) SIReadLocks continue to grow. It seems, in general, that our application code over uses Serializable... we have produced a patch that demotes some heavy-hitting queries down to Read Committed, and we will see if this makes an impact on the number of SIReadLocks. Is it interesting that only 101557 out of 7 million SIReadLocks have a pid associated with them? -Dave Owens
В списке pgsql-performance по дате отправления: