Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
От | Kevin Grittner |
---|---|
Тема | Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds |
Дата | |
Msg-id | CACjxUsOCPA+tAzxOE+f7tNhQCUjLYRpU+3k17wfjckxpLWf7pA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds (Kevin Grittner <kgrittn@gmail.com>) |
Ответы |
Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
|
Список | pgsql-hackers |
A couple things occurred to me after hitting "Send". In addition to the prior 2 points: (3) The documentation for max_pred_locks_per_relation needs a fix. Both page locks and tuple locks for the relation are counted toward the limit. In releases prior to this patch, max_pred_locks_per_relation was calculated as "max_pred_locks_per_transaction / 2". I know that people have sometimes increased max_pred_locks_per_transaction specifically to raise the limit on locks within a relation before the promotion to relation granularity occurs. It seems kinda anti-social not to support a special value for continuing that behavior or, if we don't want to do that, at least modifying pg_upgrade to set max_pred_locks_per_relation to the value that was in effect in the old version. In any event, it seems more like autovacuum_work_mem or autovacuum_vacuum_cost_limit than like effective_cache_size. Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: