From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
Cc: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, "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> |
Subject: | Re: Fix bank selection logic in SLRU |
Date: | 2024-12-10 14:07:34 |
Message-ID: | CAFiTN-vwHHrsNdpwoQN-e495TXvGKAScW8XLsdUEqDEk1woGmA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 10 Dec 2024 at 6:32 PM, Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru>
wrote:
>
>
> > 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.
+1
>
> IMO doing modulo is not necessary. And hash function is pure waste of CPU
> cycles.
I agree
—
Dilip
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Jones | 2024-12-10 14:14:41 | Re: XMLDocument (SQL/XML X030) |
Previous Message | Dilip Kumar | 2024-12-10 14:05:42 | Re: Fix bank selection logic in SLRU |