Message-ID: <4C634422.2090602@denninger.net>
Date: Wed, 11 Aug 2010 19:45:22 -0500
From: Karl Denninger <karl@denninger.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Scott Carey <scott@richrelevance.com>
CC: Scott Marlowe <scott.marlowe@gmail.com>,
	Brad Nicholson <bnichols@ca.afilias.info>,
	Greg Smith <greg@2ndquadrant.com>, Michael March <mmarch@gmail.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Completely un-tuned Postgresql benchmark results: SSD
	vs desktop HDD
References: <AANLkTikXLYc32Jyr5Fb8VeVNt6R86mCcF+0CkTHALd8W@mail.gmail.com>
	<BAE01AAD-6C69-48C7-BD2E-77E463D49903@richrelevance.com>
	<AANLkTi=km+H+mZ=yyx0_HTFZ-yU2sh85D+p5cs+ZcUSF@mail.gmail.com>
	<A1640F99-A7C5-4F04-9A25-782C46BE7DAB@richrelevance.com>
	<4C617C80.9080509@2ndquadrant.com>	<4C619300.3080400@ca.afilias.info>
	<4C6196DB.8050307@denninger.net>
	<AANLkTi=pehZj1Bb8KVusGykyEzWn__pif-87Tz2beJYj@mail.gmail.com>
	<4C619C90.3090005@denninger.net>
	<F695002B-AD66-4C8D-A76A-E3D6773EA8F1@richrelevance.com>
In-Reply-To: <F695002B-AD66-4C8D-A76A-E3D6773EA8F1@richrelevance.com>
Content-Type: multipart/mixed; boundary="------------000106090903010107040400"

This is a multi-part message in MIME format.
--------------000106090903010107040400
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Scott Carey wrote:
>
> On Aug 10, 2010, at 11:38 AM, Karl Denninger wrote:
>
> .....
>>
>> Most people who will do this won't reload it after a crash.  They'll
>> "inspect" the database and say "ok", and put it back online.  Bad
>> Karma will ensue in the future.
>
> Anyone going with something unconventional better know what they are
> doing and not just blindly plug it in and think everything will be OK.
>  I'd never recommend unconventional setups for a user that wasn't an
> expert and understood the tradeoff.
True.
>>
>> Incidentally, that risk is not theoretical either (I know about this
>> one from hard experience.  Fortunately the master was still ok and I
>> was able to force a full-table copy.... I didn't like it as the
>> database was a few hundred GB, but I had no choice.)
>
> Been there with 10TB with hardware that should have been perfectly
> safe.  5 days of copying, and wishing that pg_dump supported lzo
> compression so that the dump portion had a chance at keeping up with
> the much faster restore portion with some level of compression on to
> save the copy bandwidth.
Pipe it through ssh -C

PS: This works for SLONY and Bucardo too - set up a tunnel and then
change the port temporarily.    This is especially useful when the DB
being COPY'd across has big fat honking BYTEA fields in it, which
otherwise expand about 400% - or more - on the wire.

-- Karl


--------------000106090903010107040400
Content-Type: text/x-vcard; charset=utf-8;
 name="karl.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="karl.vcf"

begin:vcard
fn:Karl Denninger
n:Denninger;Karl
email;internet:karl@denninger.net
x-mozilla-html:TRUE
version:2.1
end:vcard


--------------000106090903010107040400--