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  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Список 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 по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
Следующее
От: Nico Williams
Дата:
Сообщение: Updating MATERIALIZED VIEWs (Re: [HACKERS] delta relations in AFTERtriggers)