Re: [EXTERNAL] Re: WIP: WAL prefetch (another approach)
От | Robert Haas |
---|---|
Тема | Re: [EXTERNAL] Re: WIP: WAL prefetch (another approach) |
Дата | |
Msg-id | CA+TgmoZrwOvaN5F3Z6Ou4UD4Y-HS9pBwWCpqwwEgL5KJqOtFAw@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: [EXTERNAL] Re: WIP: WAL prefetch (another approach) (Sait Talha Nisanci <Sait.Nisanci@microsoft.com>) |
Список | pgsql-hackers |
On Wed, Aug 26, 2020 at 9:42 AM Sait Talha Nisanci <Sait.Nisanci@microsoft.com> wrote: > I have tried combination of SSD, HDD, full_page_writes = on/off and max_io_concurrency = 10/50, the recovery times areas follows (in seconds): > > No prefetch | Default prefetch values | Default + max_io_concurrency= 50 > SSD, full_page_writes = on 852 301 197 > SSD, full_page_writes = off 1642 1359 1391 > HDD, full_page_writes = on 6027 6345 6390 > HDD, full_page_writes = off 738 275 192 The regression on HDD with full_page_writes=on is interesting. I don't know why that should happen, and I wonder if there is anything that can be done to mitigate it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: