Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Kevin Grittner <kgrittn@ymail.com> writes:
>> 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.
>
>> 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