| From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Sean Chittenden <seanc(at)joyent(dot)com> |
| Subject: | Re: WAL prefetch |
| Date: | 2018-06-16 10:06:22 |
| Message-ID: | CAEepm=3+uKBaDLgWivx9zt2-k6rr4WrVYQCK0N1+aaLrB+ZxRA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jun 16, 2018 at 9:38 PM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)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 into page 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2018-06-16 10:24:22 | Re: WAL prefetch |
| Previous Message | Tomas Vondra | 2018-06-16 09:38:59 | Re: WAL prefetch |