Re: patch for new feature: Buffer Cache Hibernation

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: patch for new feature: Buffer Cache Hibernation
Date: 2011-06-01 15:58:24
Message-ID: BANLkTikVqbuBdLe+_7u1inV=n9RkrzeqQQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, May 15, 2011 at 11:19 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> I don't think there's any need for this to get data into
> shared_buffers at all.  Getting it into the OS cache oughta be plenty
> sufficient, no?
>
> ISTM that a very simple approach here would be to save the contents of
> each shared buffer on clean shutdown, and to POSIX_FADV_WILLNEED those
> buffers on startup.

Do you mean to save the contents of the buffer pages themselves into a
hibernation file, or to save just the identities (relation/fork/block
number) of the buffers?

In the first case, getting them into the OS cache would not help
because the kernel would not recognize that data as being equivalent
to the block it is a copy of.

In the latter case, wouldn't we just trigger the same inefficient
scattered read of the data that normal database operation would
trigger, taking about the same amount of time to reach cache-warmth?
Or is POSIX_FADV_WILLNEED going to be clever about reordering and
coalescing reads?

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian Pflug 2011-06-01 16:16:21 Re: Another issue with invalid XML values
Previous Message Pavel Golub 2011-06-01 15:43:10 PQdeleteTuple function in libpq