From: Karl Denninger <karl@denninger.net>
To: Scott Carey <scott@richrelevance.com>
Cc: Scott Marlowe <scott.marlowe@gmail.com>
Cc: Brad Nicholson <bnichols@ca.afilias.info>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: Michael March <mmarch@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD
Date: Wed, 11 Aug 2010 19:45:22 -0500
Message-ID: <4C634422.2090602@denninger.net> (raw)
In-Reply-To: <F695002B-AD66-4C8D-A76A-E3D6773EA8F1@richrelevance.com>
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>
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
Attachments:karl.vcf (text/x-vcard, 122B) download
begin:vcard
fn:Karl Denninger
n:Denninger;Karl
email;internet:karl@denninger.net
x-mozilla-html:TRUE
version:2.1
end:vcard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: karl@denninger.net, scott@richrelevance.com, scott.marlowe@gmail.com, bnichols@ca.afilias.info, greg@2ndquadrant.com, mmarch@gmail.com
Subject: Re: Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD
In-Reply-To: <4C634422.2090602@denninger.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox