Re: query against pg_locks leads to large memory alloc
| От | Kevin Grittner |
|---|---|
| Тема | Re: query against pg_locks leads to large memory alloc |
| Дата | |
| Msg-id | 1408399307.93048.YahooMailNeo@web122304.mail.ne1.yahoo.com обсуждение исходный текст |
| Ответ на | Re: query against pg_locks leads to large memory alloc (Dave Owens <dave@teamunify.com>) |
| Ответы |
Re: query against pg_locks leads to large memory alloc
|
| Список | pgsql-performance |
Dave Owens <dave@teamunify.com> wrote: > max_connections = 450 ...we have found that we run out of shared > memory when max_pred_locks_per_transaction is less than 30k. >> SELECT COUNT(*) from pg_locks; > > ERROR: invalid memory alloc request size 1562436816 It gathers the information in memory to return for all those locks (I think both the normal heavyweight locks and the predicate locks do that). 450 * 30000 is 13.5 million predicate locks you could have, so they don't need a very big structure per lock to start adding up. I guess we should refactor that to use a tuplestore, so it can spill to disk when it gets to be more than work_mem. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-performance по дате отправления: