From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Gurjeet Singh <gurjeet(at)singh(dot)im>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposing pg_hibernate |
Date: | 2014-06-03 11:57:34 |
Message-ID: | CA+TgmoZtaLPinLC2nrXz2xrt_MJKK_m3VCNP8KtN0+pymc7pMg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 29, 2014 at 12:12 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> IMHO, all of these caveats, would affect a very small fraction of
>> use-cases and are eclipsed by the benefits this extension provides in
>> normal cases.
>
> I agree with you that there are only few corner cases where evicting
> shared buffers by this utility would harm, but was wondering if we could
> even save those, say if it would only use available free buffers. I think
> currently there is no such interface and inventing a new interface for this
> case doesn't seem to reasonable unless we see any other use case of
> such a interface.
It seems like it would be best to try to do this at cluster startup
time, rather than once recovery has reached consistency. Of course,
that might mean doing it with a single process, which could have its
own share of problems. But I'm somewhat inclined to think that if
recovery has already run for a significant period of time, the blocks
that recovery has brought into shared_buffers are more likely to be
useful than whatever pg_hibernate would load.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Gurjeet Singh | 2014-06-03 12:13:35 | Re: Proposing pg_hibernate |
Previous Message | Andres Freund | 2014-06-03 09:51:39 | Re: [BUGS] BUG #9652: inet types don't support min/max |