Re: Fix bank selection logic in SLRU

From: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>
To: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Fix bank selection logic in SLRU
Date: 2024-12-10 13:02:36
Message-ID: 4009750D-3EAE-4375-A7A8-3AD9922CDE1F@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 10 Dec 2024, at 15:39, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> wrote:
>
> It is not critical bug, since it doesn't hurt correctness just performance. In worst case only one bank will be used.

Ugh... yeah. IMO the problem is that we do not have protection that rejects values that are not power of 2.
If other values given system operates as if there are 2^(popcount(n)-1) banks. So if we just round down value to nearest power of 2 - we will help incorrectly configured systems to use proper amount of memory and keep performance of properly configured systems.

IMO doing modulo is not necessary. And hash function is pure waste of CPU cycles.

Best regards, Andrey Borodin.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2024-12-10 13:26:20 Re: Fix bank selection logic in SLRU
Previous Message Andrey M. Borodin 2024-12-10 12:56:06 Re: bt_index_parent_check and concurrently build indexes