From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, "Bagga, Rishu" <bagrishu(at)amazon(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "Debnath, Shawn" <sdn(at)amazon(dot)com>, vignesh C <vignesh21(at)gmail(dot)com> |
Subject: | Re: SLRUs in the main buffer pool - Page Header definitions |
Date: | 2023-02-27 13:56:33 |
Message-ID: | 50459f15-161d-d9e0-601d-aa7c64752d68@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/02/2023 22:26, Andres Freund wrote:
> On 2023-02-08 20:04:52 +0000, Bagga, Rishu wrote:
>> To summarize, our underlying effort is to move the SLRUs to the buffer
>> cache. We were working with Thomas Munro off a patch he introduced here
>> [1]. Munro’s patch moves SLRUs to the buffer cache by introducing the
>> pseudo db id 9 to denote SLRU pages, but maintains the current “raw”
>> data format of SLRU pages. The addition of page headers in our patch
>> resolves this issue [2] Munro mentions in this email [3].
>>
>> Heikki Linnakangas then introduced patch on top of Munro’s patch that
>> modularizes the storage manager, allowing SLRUs to use it [4]. Instead
>> of using db id 9, SLRUs use spcOid 9, and each SLRU is its own relation.
>> Here, Heikki simplifies the storage manager by having each struct be
>> responsible for just one fork of a relation; thus increasing
>> extensibility of the smgr API, including for SLRUs. [5] We integrated
>> our changes introducing page headers for SLRU pages, and upgrade logic
>> to Heikki’s latest patch.
>
> That doesn't explain the bulk of the changes here. Why e.g. does any of the
> above require RelationGetSmgr() to handle the fork as well? Why do we need
> smgrtruncate_multi()? And why does all of this happens as one patch?
>
> As is, with a lot of changes mushed together, without distinct explanations
> for why is what done, this patch is essentially unreviewable. It'll not make
> progress in this form.
>
> It doesn't help that much to reference prior discussions in the email I'm
> responding to - the patches need to be mostly understandable on their own,
> without reading several threads. And there needs to be explanations in the
> code as well, otherwise we'll have no chance to understand any of this in a
> few years.
Agreed. I rebased this over my rebased patch set from the other thread
at
https://www.postgresql.org/message-id/02825393-615a-ac81-0f05-f3cc2e6f875f%40iki.fi.
Attached is a new patch with only the changes relative to that patch set.
This is still messy, but now I can see what the point is: make the
SLRUs, which are tracked in the main buffer pool thanks to the other
patches, use the standard page header.
I'm not sure if I like that or not. I think we should clean up and
finish the other patches that this builds on first, and then decide if
we want to use the standard page header for the SLRUs or not. And if we
decide that we want the SLRU pages to have a page header, clean this up
or rewrite it from scratch.
- Heikki
Attachment | Content-Type | Size |
---|---|---|
0001-slru_to_buffer_cache_with_page_headers_v6.patch-reba.patch | text/x-patch | 81.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2023-02-27 13:58:51 | Re: PATCH: Using BRIN indexes for sorted output |
Previous Message | Bharath Rupireddy | 2023-02-27 13:48:14 | Re: libpq: PQgetCopyData() and allocation overhead |