Re: Patch proposal - parameter to limit amount of FPW because of hint bits per second
От | Michail Nikolaev |
---|---|
Тема | Re: Patch proposal - parameter to limit amount of FPW because of hint bits per second |
Дата | |
Msg-id | CANtu0ogLxJv_T5pDDANDfFAhx1sBzWjRMqEanjNCZHL9sFqe8w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch proposal - parameter to limit amount of FPW because of hint bits per second (Michail Nikolaev <michail.nikolaev@gmail.com>) |
Список | pgsql-hackers |
Hello, Peter. >> * Add code to _bt_killitems() that detects if it has generated an FPI, >> just to set some LP_DEAD bits. >> * Instead of avoiding the FPI when this happens, proactively call >> _bt_simpledel_pass() just before _bt_killitems() returns. Accept the >> immediate cost of setting an LP_DEAD bit, just like today, but avoid >> repeated FPIs. > Yes, I am almost sure proactively calling of_bt_simpledel_pass() will > positively impact the system on many workloads. But also I am almost > sure it will not change the behavior of the incident I mention - > because it is not related to multiple checkpoints. I just realized what it seems to be dangerous approache because of locking mechanism. Currently _bt_killitems requires only read lock but _bt_simpledel_pass required write lock (it ends with _bt_delitems_delete). It will required to increase locking mode in order to call _bt_simpledel_pass. Such a change may negatively affect many workloads because of write lock during scanning - and it is really hard to to prove absence of regression (have no idea how). Thanks, Michail.
В списке pgsql-hackers по дате отправления: