Re: Refactoring the checkpointer's fsync request queue
От | Shawn Debnath |
---|---|
Тема | Re: Refactoring the checkpointer's fsync request queue |
Дата | |
Msg-id | 20190404041945.GA16205@f01898859afd.ant.amazon.com обсуждение исходный текст |
Ответ на | Re: Refactoring the checkpointer's fsync request queue (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Refactoring the checkpointer's fsync request queue
|
Список | pgsql-hackers |
On Thu, Apr 04, 2019 at 02:01:14PM +1300, Thomas Munro wrote: > On Thu, Apr 4, 2019 at 11:39 AM Thomas Munro <thomas.munro@gmail.com> wrote: > > ... Perhaps > > that is an argument for putting the sync handler number *inside* the > > FileTag, since we currently intend to do that with smgr IDs in > > BufferTag (stealing space from ForkNumber). > > Here is a version like that. I like it better this way, and the extra > space can be clawed back by using 16 bit types to hold the fork number > and sync handler number. +typedef struct FileTag +{ + int16 handler; /* SyncRequstHandler value, saving space */ + int16 forknum; /* ForkNumber, saving space */ + RelFileNode rnode; + BlockNumber segno; +} FileTag; Definitely makes sense. v16 looks good to me. Thanks! -- Shawn Debnath Amazon Web Services (AWS)
В списке pgsql-hackers по дате отправления: