Re: [EXTERNAL] Re: WIP: WAL prefetch (another approach)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Sait Talha Nisanci <Sait(dot)Nisanci(at)microsoft(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [EXTERNAL] Re: WIP: WAL prefetch (another approach)
Date: 2020-08-27 13:51:56
Message-ID: CA+TgmoZrwOvaN5F3Z6Ou4UD4Y-HS9pBwWCpqwwEgL5KJqOtFAw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 26, 2020 at 9:42 AM Sait Talha Nisanci
<Sait(dot)Nisanci(at)microsoft(dot)com> wrote:
> I have tried combination of SSD, HDD, full_page_writes = on/off and max_io_concurrency = 10/50, the recovery times are as 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2020-08-27 13:55:33 Re: [EXTERNAL] Re: WIP: WAL prefetch (another approach)
Previous Message Robert Haas 2020-08-27 13:50:09 Re: factorial function/phase out postfix operators?