Re: Patch proposal - parameter to limit amount of FPW because of hint bits per second

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.

In response to

Browse pgsql-hackers by date

  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