Re: [HACKERS] Point in Time Recovery
От | Simon@2ndquadrant.com |
---|---|
Тема | Re: [HACKERS] Point in Time Recovery |
Дата | |
Msg-id | NOEFLCFHBPDAFHEIPGBOCEHDCCAA.simon@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Point in Time Recovery (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Point in Time Recovery
|
Список | pgsql-patches |
> Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Now, if you say people will rarely turn archiving on/off, then one > > > parameter seems to make more sense. > > > > I really can't envision a situation where people would do that. If you > > need PITR at all then you need it 24x7. > I agree. The second parameter is only there to clarify the intent. 8.0 does introduce two good reasons to turn it on/off, however: - index build speedups - COPY speedups I would opt to make enabling/disabling archive_command require a postmaster restart. That way there would be no capability to take advantage of the incentive to turn it on/off. For TODO: It would be my intention (in 8.1) to make those available via switches e.g. NOT LOGGED options on CREATE INDEX and COPY, to allow users to take advantage of the no logging optimization without turning off PITR system wide. (Just as this is possible in Oracle and Teradata). I would also aim to make the first Insert Select into an empty table not logged (optionally). This is an important optimization for Oracle, teradata and DB2 (which uses NOT LOGGED INITIALLY). Best Regards, Simon Riggs
В списке pgsql-patches по дате отправления: