From: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch proposal - parameter to limit amount of FPW because of hint bits per second |
Date: | 2022-03-24 08:03:59 |
Message-ID: | CANtu0ogLxJv_T5pDDANDfFAhx1sBzWjRMqEanjNCZHL9sFqe8w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2022-03-24 08:08:38 | Re: Allow file inclusion in pg_hba and pg_ident files |
Previous Message | Michael Paquier | 2022-03-24 07:50:31 | Re: Allow file inclusion in pg_hba and pg_ident files |