Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
От | ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) |
---|---|
Тема | Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds |
Дата | |
Msg-id | d8jk2a9crgb.fsf@dalvik.ping.uio.no обсуждение исходный текст |
Ответ на | [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)) |
Ответы |
Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
|
Список | 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 по дате отправления: