Re: [HACKERS] Proposal : For Auto-Prewarm.
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Proposal : For Auto-Prewarm. |
Дата | |
Msg-id | CA+TgmoY0Rjw=T-swpotmpQpzOPE9ZecOq=HZ2pjMJ9OZ4c8DVg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Proposal : For Auto-Prewarm. (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Proposal : For Auto-Prewarm.
|
Список | pgsql-hackers |
On Wed, Feb 22, 2017 at 4:06 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 2/10/17 15:12, Robert Haas wrote: >> Right. I can't see why you'd want to be able to separately control >> those two things. If you're not dumping, you don't want to load; if >> you're not loading, you don't want to dump. > > What about the case where you want to prewarm a standby from the info > from the primary (or another standby)? I think it's OK to treat that as something of a corner case. There's nothing to keep you from doing that today: just use pg_buffercache to dump a list of blocks on one server, and then pass those blocks to pg_prewarm on another server. The point of this patch, AIUI, is to automate a particularly common case of that, which is to dump before shutdown and load upon startup. It doesn't preclude other things that people want to do. I suppose we could have an SQL-callable function that does an immediate dump (without starting a worker). That wouldn't hurt anything, and might be useful in a case like the one you mention. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: