I'm sure this doesn't apply to anyone on this thread, just a general reminder to all you DBA's out there who sometimes are too busy to implement PITR until after a disaster strikes. I know that in the past I've personally been guilty of this on several occasions.
--Denis
EnterpriseDB (yeah, rah, rah...)
On 8/1/06, Merlin Moncure <mmoncure@xxxxxxxxx> wrote:
On 8/1/06, George Pavlov <gpavlov@xxxxxxxxxxxxxx > wrote:
> I am looking for some general guidelines on what is the performance
> overhead of enabling point-in-time recovery (archive_command config) on
> an 8.1 database. Obviously it will depend on a multitude of factors, but
> some broad-brush statements and/or anecdotal evidence will suffice.
> Should one worry about its performance implications? Also, what can one
> do to mitigate it?
pitr is extremely cheap both in performance drag and administation
overhead for the benefits it provides. it comes almost for free, just
make sure you can handle all the wal files and do sane backup
scheduling. in fact, pitr can actually reduce the load on a server
due to running less frequent backups. if your server is heavy i/o
loaded, it might take a bit of planning.
merlin
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
