Re: query against pg_locks leads to large memory alloc

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
>> Dave Owens <dave(at)teamunify(dot)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.
>
>> 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.
>
> Seems to me the bigger issue is why does he need such a huge
> max_pred_locks_per_transaction setting?  It's hard to believe that
> performance wouldn't tank with 10 million predicate locks active.
> Whether you can do "select * from pg_locks" seems pretty far down
> the list of concerns about this setting.

It would be interesting to know more about the workload which is
capable of that, but it would be a lot easier to analyze what's
going on if we could look at where those locks are being used (in
summary, of course -- nobody can make sense of 10 million detail
lines).  About all I can think to ask at this point is: how many
total tables and indexes are there in all databases in this cluster
(counting each partition of a partitioned table as a separate
table)?  With the promotion of finer-grained locks to courser ones
this should be pretty hard to hit without a very large number of
tables.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company