From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(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 17:02:55 |
Message-ID: | BANLkTikhGC-bMvJ56EVa8=o16P1ioktPBQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 1, 2011 at 11:58 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> 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?
The latter.
> 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?
It would be nice if POSIX_FADV_WILLNEED is clever enough to reorder
and coalesce, but even if it isn't, we can help it along by doing all
the reads from any given file one after another and in increasing
block number order.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-06-01 17:19:53 | Re: [HACKERS] DOCS: SGML identifier may not exceed 44 characters |
Previous Message | Robert Haas | 2011-06-01 16:55:21 | Re: [HACKERS] DOCS: SGML identifier may not exceed 44 characters |