Re: Proposing pg_hibernate
От | Robert Haas |
---|---|
Тема | Re: Proposing pg_hibernate |
Дата | |
Msg-id | CA+TgmoZtaLPinLC2nrXz2xrt_MJKK_m3VCNP8KtN0+pymc7pMg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposing pg_hibernate (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Proposing pg_hibernate
|
Список | pgsql-hackers |
On Thu, May 29, 2014 at 12:12 AM, Amit Kapila <amit.kapila16@gmail.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
В списке pgsql-hackers по дате отправления: