Re: query against pg_locks leads to large memory alloc - Mailing list pgsql-performance

On Mon, Aug 18, 2014 at 2:21 PM, Matheus de Oliveira
<matioli.matheus@gmail.com> wrote:
> Do you really need such large values? What is your max_connections value?

max_connections = 450 ...we have found that we run out of shared
memory when max_pred_locks_per_transaction is less than 30k.

On Mon, Aug 18, 2014 at 2:29 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> performance of any query to pg_locks is proportional to the setting of
> max_locks_per_transaction.  still, something is awry here.  can you
> 'explain' that query?

tudb=# explain SELECT mode, count(mode) AS count FROM pg_locks GROUP
BY mode ORDER BY mode;
                                     QUERY PLAN
-------------------------------------------------------------------------------------
 Sort  (cost=0.63..0.65 rows=200 width=32)
   Sort Key: l.mode
   ->  HashAggregate  (cost=0.30..0.32 rows=200 width=32)
         ->  Function Scan on pg_lock_status l  (cost=0.00..0.10
rows=1000 width=32)
(4 rows)


> SELECT COUNT(*) from pg_locks;

ERROR:  invalid memory alloc request size 1562436816