| 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:36:30 |
| Message-ID: | 02825393-615a-ac81-0f05-f3cc2e6f875f@iki.fi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 27/02/2023 15:31, Heikki Linnakangas wrote:
> 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.
Forgot to include the new "slrulist.h" file in the previous patch, fixed
here.
- Heikki
| Attachment | Content-Type | Size |
|---|---|---|
| v3-0001-Have-separate-SMmgrRelation-per-fork-rename-it-to.patch | text/x-patch | 165.4 KB |
| v3-0002-WIP-SLRUs.patch | text/x-patch | 148.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2023-02-27 13:48:14 | Re: libpq: PQgetCopyData() and allocation overhead |
| Previous Message | Andrew Dunstan | 2023-02-27 13:36:12 | Re: meson vs make: missing/inconsistent ENV |