Re: Make relfile tombstone files conditional on WAL level
От | Robert Haas |
---|---|
Тема | Re: Make relfile tombstone files conditional on WAL level |
Дата | |
Msg-id | CA+Tgmob0zRX+WA9RibG9Ojhzr8_a0MUKH2WSgyfyOROVtDnsOQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Make relfile tombstone files conditional on WAL level (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Make relfile tombstone files conditional on WAL level
|
Список | pgsql-hackers |
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. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: