Re: Logical tape pause/resume - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Logical tape pause/resume
Date
Msg-id eea7dfd0-05f2-d028-8926-0262ee4f00f5@iki.fi
Whole thread Raw
In response to Re: Logical tape pause/resume  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers
On 10/04/2016 07:06 PM, Claudio Freire wrote:
> On Tue, Oct 4, 2016 at 7:47 AM, Heikki Linnakangas <hlinnaka@iki.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




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Extend framework from commit 53be0b1ad to report latch waits.
Next
From: Robert Haas
Date:
Subject: Re: pgbench more operators & functions