Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id BE72C632BCF
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue, 10 Aug 2010 15:54:27 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 56295-02
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue, 10 Aug 2010 18:54:15 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26])
	by mail.postgresql.org (Postfix) with ESMTP id 182A6632459
	for <pgsql-performance@postgresql.org>;
	Tue, 10 Aug 2010 15:54:15 -0300 (ADT)
Message-ID: <4C61A054.6080400@ca.afilias.info>
Date: Tue, 10 Aug 2010 14:54:12 -0400
From: Brad Nicholson <bnichols@ca.afilias.info>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: Karl Denninger <karl@denninger.net>
CC: Scott Marlowe <scott.marlowe@gmail.com>,
	Greg Smith <greg@2ndquadrant.com>,
	Scott Carey <scott@richrelevance.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>
In-Reply-To: <4C619C90.3090005@denninger.net>
Content-Type: multipart/alternative;
	boundary="------------010004040602030201030604"
X-Authenticated: True
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.31 tagged_above=-10 required=5
	tests=BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201008/120
X-Sequence-Number: 39963

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

  On 8/10/2010 2:38 PM, Karl Denninger wrote:
> Scott Marlowe wrote:
>> On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger<karl@denninger.net>  wrote:
>>    
>>> ANY disk that says "write is complete" when it really is not is entirely
>>> unsuitable for ANY real database use.  It is simply a matter of time
>>>      
>>
>> What about read only slaves where there's a master with 100+spinning
>> hard drives "getting it right" and you need a half dozen or so read
>> slaves?  I can imagine that being ok, as long as you don't restart a
>> server after a crash without checking on it.
>>    
> A read-only slave isn't read-only, is it?
>
> I mean, c'mon - how does the data get there?
>

A valid case is a Slony replica if used for query offloading (not for 
DR).  It's considered a read-only subscriber from the perspective of 
Slony as only Slony can modify the data  (although you are technically 
correct, it is not read only - controlled write may be more accurate).

  In case of failure, a rebuild + resubscribe gets you back to the same 
consistency.  If you have high IO requirements, and don't have the 
budget to rack up extra disk arrays to meet them, it could be an option.

-- 
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.


--------------010004040602030201030604
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 8/10/2010 2:38 PM, Karl Denninger wrote:
    <blockquote cite="mid:4C619C90.3090005@denninger.net" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Scott Marlowe wrote:
      <blockquote
        cite="mid:AANLkTi=pehZj1Bb8KVusGykyEzWn__pif-87Tz2beJYj@mail.gmail.com"
        type="cite">
        <pre wrap="">On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:karl@denninger.net">&lt;karl@denninger.net&gt;</a> wrote:
  </pre>
        <blockquote type="cite">
          <pre wrap="">ANY disk that says "write is complete" when it really is not is entirely
unsuitable for ANY real database use. &nbsp;It is simply a matter of time
    </pre>
        </blockquote>
        <pre wrap=""><!---->
What about read only slaves where there's a master with 100+spinning
hard drives "getting it right" and you need a half dozen or so read
slaves?  I can imagine that being ok, as long as you don't restart a
server after a crash without checking on it.
  </pre>
      </blockquote>
      A read-only slave isn't read-only, is it?<br>
      <br>
      I mean, c'mon - how does the data get there?<br>
      <br>
    </blockquote>
    <br>
    A valid case is a Slony replica if used for query offloading (not
    for DR).&nbsp; It's considered a read-only subscriber from the
    perspective of Slony as only Slony can modify the data&nbsp; (although
    you are technically correct, it is not read only - controlled write
    may be more accurate).&nbsp; <br>
    <br>
    &nbsp;In case of failure, a rebuild + resubscribe gets you back to the
    same consistency.&nbsp; If you have high IO requirements, and don't have
    the budget to rack up extra disk arrays to meet them, it could be an
    option.<br>
    <pre class="moz-signature" cols="72">-- 
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.</pre>
  </body>
</html>

--------------010004040602030201030604--