Re: How to avoid generation huge pg_xlog files during VACUUM , REINDEX maintenance task.

From: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Shrinivas Devarkonda *EXTERN*" <shrinivasdevarkonda(at)gmail(dot)com>, "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: How to avoid generation huge pg_xlog files during VACUUM , REINDEX maintenance task.
Date: 2014-04-29 08:20:33
Message-ID: A737B7A37273E048B164557ADEF4A58B17CF49F7@ntex2010i.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Shrinivas Devarkonda wrote:
> We have a High transactional Database with Streamline Replication in place across two Data Centers
> with the dedicated leased line. The SR works awesome all time.
>
> We do vacuum+reindex of few imp high transactional tables (not an entire database) which generates
> many pg_xlog files indeed creates Huge spike of Data transfer between two networks and burst the
> bandwidth only during this time.
>
> Can we avoid the generating pg_xlog files for vacuum + reindex ? Are any other solutions to it ? Our
> vacuum + reindex is very very minimal and based on dead rows stats.
>
> PG version : 9.0.4 ( on 64 bit OS).

I don't think that your VACUUM and REINDEX is very minimal, because otherwise
it would not generate a lot of WAL (pg_xlog files). The WAL captures the
changes to the database, and they must be replayed to the standby.

If you really need these maintenance operations, that's the price.

Yours,
Laurenz Albe

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Rob Richardson 2014-04-29 18:13:37 Slow backups over VPN
Previous Message Albe Laurenz 2014-04-29 08:09:02 Re: about the copy command