Re: Logical tape pause/resume

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Geoghegan <pg(at)heroku(dot)com>
Subject: Re: Logical tape pause/resume
Date: 2016-10-04 16:12:53
Message-ID: eea7dfd0-05f2-d028-8926-0262ee4f00f5@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/04/2016 07:06 PM, Claudio Freire wrote:
> On Tue, Oct 4, 2016 at 7:47 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> 1. The first patch changes the way we store the logical tapes on disk.
>> Instead of using indirect blocks, HFS style, the blocks form a linked list.
>> Each block has a trailer, with the block numbers of the previous and next
>> block of the tape. That eliminates the indirect blocks, which simplifies the
>> code quite a bit, and makes it simpler to implement the pause/resume
>> functionality in the second patch. It also immediately reduces the memory
>> needed for the buffers, from 3 to 1 block per tape, as we don't need to hold
>> the indirect blocks in memory.
>
> Doesn't that make prefetching more than a buffer ahead harder?

Yes, indeed. That's a potential downside, if we wanted to do that. We
rely wholly on OS readahead for that currently, so it doesn't matter. I
don't think we want to start issuing explicit pre-fetching calls here
any time soon. But if we did, we could presume that the pages in
sequential order for prefetching purposes, and that would work pretty
well in practice (that's what the OS readahead is doing for us now). Or
we could try to enforce that by allocating blocks in larger chunks.

In short, I'm OK with that.

- Heikki

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-10-04 16:15:21 Re: pgbench more operators & functions
Previous Message Alvaro Herrera 2016-10-04 16:11:57 Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.