Re: Make relfile tombstone files conditional on WAL level

On Mon, Feb 7, 2022 at 10:13 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Mon, Feb 7, 2022 at 11:31 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > For RelFileNode also we need to use 2, 32-bit integers so that we do
> > not add extra alignment padding because there are a few more
> > structures that include RelFileNode e.g. xl_xact_relfilenodes,
> > RelFileNodeBackend, and many other structures.
>
> Are you sure that kind of stuff is really important enough to justify
> the code churn? I don't think RelFileNodeBackend is used widely enough
> or in sufficiently performance-critical places that we really need to
> care about a few bytes of alignment padding. xl_xact_relfilenodes is
> more concerning because that goes into the WAL format, but I don't
> know that we use it often enough for an extra 4 bytes per record to
> really matter, especially considering that this proposal also adds 4
> bytes *per relfilenode* which has to be a much bigger deal than a few
> padding bytes after 'nrels'. The reason why BufferTag matters a lot is
> because (1) we have an array of this struct that can easily contain a
> million or eight entries, so the alignment padding adds up a lot more
> and (2) access to that array is one of the most performance-critical
> parts of PostgreSQL.

I agree with you that adding 4 extra bytes to these structures might
not be really critical. I will make the changes based on this idea
and see how the changes look.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com