Re: [PATCH] Add GUCs for predicate lock promotion thresholds

From: Kevin Grittner <kgrittn(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add GUCs for predicate lock promotion thresholds
Date: 2017-01-20 23:25:24
Message-ID: CACjxUsOCPA+tAzxOE+f7tNhQCUjLYRpU+3k17wfjckxpLWf7pA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nico Williams 2017-01-20 23:38:22 Updating MATERIALIZED VIEWs (Re: delta relations in AFTER triggers)
Previous Message Kevin Grittner 2017-01-20 22:41:53 Re: [PATCH] Add GUCs for predicate lock promotion thresholds