Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
Date
Msg-id CACjxUsOCPA+tAzxOE+f7tNhQCUjLYRpU+3k17wfjckxpLWf7pA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
List 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 by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
Next
From: Nico Williams
Date:
Subject: Updating MATERIALIZED VIEWs (Re: [HACKERS] delta relations in AFTERtriggers)