From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Shawn Debnath <clocksweep(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
Subject: | Re: SLRUs in the main buffer pool, redux |
Date: | 2023-02-27 13:31:55 |
Message-ID: | c119ffc2-110e-f614-09ab-73d046238982@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20/01/2023 19:00, Shawn Debnath wrote:
> On Mon, Jul 25, 2022 at 11:54:36AM +0300, Heikki Linnakangas wrote:
>
>> Oh I just saw that you had a comment about that in the patch and had hacked
>> around it. Anyway, calling ResourceOwnerEnlargeBuffers() might be a
>> solution. Or switch to a separate "CriticalResourceOwner" that's guaranteed
>> to have enough pre-allocated space, before entering the critical section.
>
> Wanted to bump up this thread. Rishu in my team posted a patch in the other
> SLRU thread [1] with the latest updates and fixes and looks like performance
> numbers do not show any regression. This change is currently in the
> January commitfest [2] as well. Any feedback would be appreciated!
Here's a rebased set of patches.
The second patch is failing the pg_upgrade tests. Before I dig into
that, I'd love to get some feedback on this general approach.
- Heikki
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Have-separate-SMmgrRelation-per-fork-rename-it-to.patch | text/x-patch | 165.4 KB |
v2-0002-WIP-SLRUs.patch | text/x-patch | 147.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2023-02-27 13:35:52 | Re: Stale references to guc.c in comments/tests |
Previous Message | Bharath Rupireddy | 2023-02-27 13:24:00 | Re: Allow logical replication to copy tables in binary format |