Re: Make relfile tombstone files conditional on WAL level
От | Dilip Kumar |
---|---|
Тема | Re: Make relfile tombstone files conditional on WAL level |
Дата | |
Msg-id | CAFiTN-sTKY+1H+WmSOdSxB5wFb4AJz5LUrjMZsEzXz3z0XUJAg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Make relfile tombstone files conditional on WAL level (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Mon, Feb 7, 2022 at 10:13 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Mon, Feb 7, 2022 at 11:31 AM Dilip Kumar <dilipbalaut@gmail.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
В списке pgsql-hackers по дате отправления: