| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Sean Chittenden <seanc(at)joyent(dot)com> |
| Subject: | Re: WAL prefetch |
| Date: | 2018-06-27 15:25:05 |
| Message-ID: | e66805a4-dd44-3b80-b636-957434289549@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 06/27/2018 11:44 AM, Konstantin Knizhnik wrote:
>
> ...
>
> I have improved my WAL prefetch patch. The main reason of slowdown
> recovery speed with enabled prefetch was that it doesn't take in account
> initialized pages (XLOG_HEAP_INIT_PAGE)
> and doesn't remember (cache) full page writes.
> The main differences of new version of the patch:
>
> 1. Use effective_cache_size as size of cache of prefetched blocks
> 2. Do not prefetch blocks sent in shared buffers
> 3. Do not prefetch blocks for RM_HEAP_ID with XLOG_HEAP_INIT_PAGE bit set
> 4. Remember new/fpw pages in prefetch cache, to avoid prefetch them for
> subsequent WAL records.
> 5. Add min/max prefetch lead parameters to make it possible to
> synchronize speed of prefetch with speed of replay.
> 6. Increase size of open file cache to avoid redundant open/close
> operations.
>
Thanks. I plan to look at it and do some testing, but I won't have time
until the end of next week (probably).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2018-06-27 15:38:31 | Re: effect of JIT tuple deform? |
| Previous Message | Tomas Vondra | 2018-06-27 15:19:11 | Re: effect of JIT tuple deform? |