| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
| Cc: | 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-16 09:38:59 |
| Message-ID: | 638f556a-ef64-9191-1e16-06ab7ff4b1ce@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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:
>>> On Thu, Jun 14, 2018 at 1:09 AM, Konstantin Knizhnik
>>> <k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
>>>> pg_wal_prefetch function will infinitely traverse WAL and prefetch block
>>>> references in WAL records
>>>> using posix_fadvise(WILLNEED) system call.
>>> Hi Konstantin,
>>>
>>> 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).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2018-06-16 10:06:22 | Re: WAL prefetch |
| Previous Message | Dilip Kumar | 2018-06-16 08:36:55 | Re: ON CONFLICT DO NOTHING on pg_dump |