Re: WAL prefetch
От | Thomas Munro |
---|---|
Тема | Re: WAL prefetch |
Дата | |
Msg-id | CAEepm=3+uKBaDLgWivx9zt2-k6rr4WrVYQCK0N1+aaLrB+ZxRA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WAL prefetch (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: WAL prefetch
|
Список | pgsql-hackers |
On Sat, Jun 16, 2018 at 9:38 PM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > On 06/15/2018 08:01 PM, Andres Freund wrote: >> On 2018-06-14 10:13:44 +0300, Konstantin Knizhnik wrote: >>> On 14.06.2018 09:52, Thomas Munro wrote: >>>> Why stop at the page cache... what about shared buffers? >>> >>> It is good question. I thought a lot about prefetching directly to shared >>> buffers. >> >> I think that's definitely how this should work. I'm pretty strongly >> opposed to a prefetching implementation that doesn't read into s_b. > > Could you elaborate why prefetching into s_b is so much better (I'm sure it has advantages, but I suppose prefetching intopage cache would be much easier to implement). posix_fadvise(POSIX_FADV_WILLNEED) might already get most of the speed-up available here in the short term for this immediate application, but in the long term a shared buffers prefetch system is one of the components we'll need to support direct IO. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: