Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds |
Дата | |
Msg-id | 8545.1483640374@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-hackers |
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker) writes: > 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. FWIW, interdependent GUC defaults are generally unworkable. See commit a16d421ca and the sorry history that led up to it. I think you could make it work as a fraction, though. regards, tom lane
В списке pgsql-hackers по дате отправления: