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

From ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Subject Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
Date
Msg-id d8jk2a9crgb.fsf@dalvik.ping.uio.no
Whole thread Raw
In response to [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Responses Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes:

> One thing I don't like about this patch is that if a user has increased
> max_pred_locks_per_transaction, they need to set
> max_pred_locks_per_relation to half of that to retain the current
> behaviour, or they'll suddenly find themselves with a lot more relation
> locks.  If it's possible to make a GUCs default value dependent on the
> value of another, that could be a solution.  Otherwise, the page lock
> threshold GUC could be changed to be expressed as a fraction of
> max_pred_locks_per_transaction, to keep the current behaviour.

Another option would be to have a special sentinel (e.g. -1) which is
the default, and keeps the current behaviour.

-- 
"A disappointingly low fraction of the human race is,at any given time, on fire." - Stig Sandbeck Mathisen




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Fix possible crash reading pg_stat_activity.