Message-ID: <4E6E3506.8070501@peak6.com>
Date: Mon, 12 Sep 2011 11:36:22 -0500
From: Shaun Thomas <sthomas@peak6.com>
Reply-To: <sthomas@peak6.com>
Organization: Peak6
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Claudio Freire <klaussfreire@gmail.com>
CC: Andy Colson <andy@squeakycode.net>, Igor Chudov <ichudov@gmail.com>,
	<pgsql-performance@postgresql.org>
Subject: Re: Postgres for a "data warehouse", 5-10 TB
References: 
 <CAMhtkAbK7saRO_Tayb1nS3YLWN=Wns=Ci47qs-3YbX0T2+hkpA@mail.gmail.com>
	<4E6CC2BB.1060704@squeakycode.net>
	<CAGTBQpbL5gvv-pk3RYBO-B1FMBfOPXcKG7GaYzHWogchJNLePA@mail.gmail.com>
In-Reply-To: 
 <CAGTBQpbL5gvv-pk3RYBO-B1FMBfOPXcKG7GaYzHWogchJNLePA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
content-transfer-encoding: 7bit

On 09/11/2011 09:27 AM, Claudio Freire wrote:

> I have used slony to do database migration. It is a pain to set up,
> but it saves you hours of downtime.

I've had to shoot this option down in two separate upgrade scenarios in 
two different companies. Theoretically it's possible, but slony is based 
on triggers. If you have an OLTP database with frequent writes, that 
overhead (firing the trigger, storing the replicated data, reading the 
replication log, traffic to the upgrade node) can literally kill your 
application. Downtime is one thing, but maintenance windows can be 
planned. Ruining application performance for an undetermined length of 
time is probably worse.

Thankfully 8.4 added pg_migrator/pg_upgrade, so that kind of pain is 
probably over for the most part. But even without it, 8.4 and above have 
parallel restore, which can drop upgrade times down to a fraction of 
their former length.

-- 
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas@peak6.com

______________________________________________

See http://www.peak6.com/email-disclaimer/ for terms and conditions related to this email