On 2018-06-16 23:31:49 +0300, Konstantin Knizhnik wrote: > > > On 16.06.2018 22:23, Andres Freund wrote: > > Hi, > > > > On 2018-06-13 16:09:45 +0300, Konstantin Knizhnik wrote: > > > Usage: > > > 1. At master: create extension wal_prefetch > > > 2. At replica: Call pg_wal_prefetch() function: it will not return until > > > you > > > interrupt it. > > FWIW, I think the proper design would rather be a background worker that > > does this work. Forcing the user to somehow coordinate starting a > > permanently running script whenever the database restarts isn't > > great. There's also some issues around snapshots preventing vacuum > > (which could be solved, but not nicely). > > As I already wrote, the current my approach with extension and > pg_wal_prefetch function called by user can be treated only as prototype > implementation which can be used to estimate efficiency of prefetch. But in > case of prefetching in shared buffers, one background worker will not be > enough. Prefetch can can speedup recovery process if it performs reads in > parallel or background. So more than once background worker will be needed > for prefetch if we read data to Postgres shared buffers rather then using > posix_prefetch to load page in OS cache.
Sure, we'd need more than one to get the full benefit, but that's not really hard. You'd see benefit even with a single process, because WAL replay often has a lot of other bottlenecks too. But no reason to not have multiple ones. Greetings, Andres Freund
