public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bagga, Rishu <[email protected]>
To: Andres Freund <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: SLRUs in the main buffer pool - Page Header definitions
Date: Thu, 23 Jun 2022 20:25:21 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
Hi Andres,
Thanks for your response.
To answer your questions:
>> 3. A flag to identify if the page is a relational or BufferedObject
>Why is this needed in the page header?
Now that we are dealing with two different type of page headers, we need to know how to interpret any given page. We need to use pd_flags to determine this.
>How are you proposing to deal with this in the "key" to "offset in >SLRU"
>mapping? E.g. converting a xid to an offset in the pg_xact SLRU. I >assume
>you're thinking to deal with this by making the conversion math a bit >more
>complicated?
You’re right; we would have to account for this in the conversion math between the ‘key’ and ‘offset’. The change to the macros would be as following:
#define MULTIXACT_OFFSETS_PER_PAGE ((BLCKSZ - SizeOfBufferedObjectPageHeaderData) / sizeof(MultiXactOffset))
Additionally, we need to account for the size of the page header when reading and writing multixacts in memory based off of the entryno.
Rishu Bagga
Amazon Web Services (AWS)
On 6/22/22, 2:40 PM, "Andres Freund" <[email protected]> wrote:
Hi,
On 2022-06-22 21:06:29 +0000, Bagga, Rishu wrote:
> 3. A flag to identify if the page is a relational or BufferedObject
Why is this needed in the page header?
> Using the new BufferedObject page header will be space efficient but
> introduces a significant change in the codebase to now track two types
> of page header data. During upgrade, all SLRU files that exist on the
> system must be converted to the new format with page header. This will
> require rewriting all the SLRU pages with the page header as part of
> pg_upgrade.
How are you proposing to deal with this in the "key" to "offset in SLRU"
mapping? E.g. converting a xid to an offset in the pg_xact SLRU. I assume
you're thinking to deal with this by making the conversion math a bit more
complicated?
Greetings,
Andres Freund
view thread (16+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: SLRUs in the main buffer pool - Page Header definitions
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox