Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id F33523A6EE5
	for <pgsql-general@postgresql.org>;
	Fri,  6 Jul 2012 00:02:54 -0300 (ADT)
Received: from mail-pb0-f46.google.com ([209.85.160.46])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <ringerc@ringerc.id.au>) id 1Smyon-0000pD-34
	for pgsql-general@postgresql.org; Fri, 06 Jul 2012 03:02:53 +0000
Received: by pbbrp8 with SMTP id rp8so13822261pbb.19
	for <pgsql-general@postgresql.org>;
	Thu, 05 Jul 2012 20:02:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=google.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type:x-gm-message-state;
	bh=KqrNzLioGV7vjGOYl/cWLblr3690G2fEMMCXSJAoM90=;
	b=bVuORSRD1TnmKzhMo2G4iE75H+RgecPNEqvrpwieEpvYRa3rPtaFTlEvh80UOAVFpJ
	e7qWXZ/nVNEh4yRnrBpKhRtuXxTgNTjYOrQiadelrH+ZSYLWEwjAHt+Emm48erEM1cg3
	PZrf06JV7i00dt7tbaKM0Pzsj8T1nKBEOUuuyyCvG6qior5a3y/dZ8rwPZMOLAOidtuu
	fHWWpWrzpMG1Jsvy98tYgrH5Z/Q7TX57V+N2GJxzAKsntPZ+oLM33AbLePj+yhFvVHu4
	/icJxHG4+x8XrlKbgmqbDafoScCEalDw5YkDaFg02+brQJMQJml1ewG0cpoBwVGY2C7T
	7jMw==
Received: by 10.66.87.70 with SMTP id v6mr41769868paz.14.1341543759157;
	Thu, 05 Jul 2012 20:02:39 -0700 (PDT)
Received: from ayaki.localdomain (124-169-169-118.dyn.iinet.net.au.
	[124.169.169.118])
	by mx.google.com with ESMTPS id qa5sm20931395pbb.19.2012.07.05.20.02.36
	(version=SSLv3 cipher=OTHER); Thu, 05 Jul 2012 20:02:38 -0700 (PDT)
Message-ID: <4FF6554A.2040303@ringerc.id.au>
Date: Fri, 06 Jul 2012 11:02:34 +0800
From: Craig Ringer <ringerc@ringerc.id.au>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120605 Thunderbird/13.0
MIME-Version: 1.0
To: Samuel Gendler <sgendler@ideasculptor.com>,
	"pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Subject: Re: [PERFORM] The need for clustered indexes to boost TPC-V
	performance
References: 
 <66CE997FB523C04E9749452273184C6C137CB88A86@exch-mbx-113.vmware.com>
	<4FF3D80F.9040408@ringerc.id.au>
	<66CE997FB523C04E9749452273184C6C137CB88CDD@exch-mbx-113.vmware.com>
	<4FF63553.4080300@ringerc.id.au>
	<CAEV0TzAaZCboBk=tEkqPH0wiCGffzECUmghOw7QeTfzSMdLDWQ@mail.gmail.com>
	<CAEV0TzCi3Bh2xK84dS4V=LOoy-ZeggGCGcUeHf8hnH118pzOzg@mail.gmail.com>
In-Reply-To: 
 <CAEV0TzCi3Bh2xK84dS4V=LOoy-ZeggGCGcUeHf8hnH118pzOzg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------000804020106070503000006"
X-Gm-Message-State: 
 ALoCoQnweIbucr69b64hEZmXOe4ShQvPfHk6J3+tnrQvHaIUH9k+OHwg38aJMtEJ8CDuMr76WEWN
X-Pg-Spam-Score: -1.9 (-)
X-Archive-Number: 201207/92
X-Sequence-Number: 188603

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

On 07/06/2012 09:33 AM, Samuel Gendler wrote:
>
> Some other potential issues - with only 10MB of work_mem, you might be 
> gong to temp space on disk more than you realize.  Explain analyze 
> might reveal that, but only if you happen to pick a query that exceeds 
> work_mem on at least one step.
Rather than hunting blindly with EXPLAIN ANALYZE it's better to just 
turn log_temp_files on and see what's reported.

--
Craig Ringer



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

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/06/2012 09:33 AM, Samuel Gendler
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAEV0TzCi3Bh2xK84dS4V=LOoy-ZeggGCGcUeHf8hnH118pzOzg@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=ISO-8859-1">
      <div>
        <div><br>
        </div>
        <div>Some other potential issues - with only 10MB of work_mem,
          you might be gong to temp space on disk more than you realize.
          &nbsp;Explain analyze might reveal that, but only if you happen to
          pick a query that exceeds work_mem on at least one step.</div>
      </div>
    </blockquote>
    Rather than hunting blindly with EXPLAIN ANALYZE it's better to just
    turn log_temp_files on and see what's reported.<br>
    <br>
    --<br>
    Craig Ringer<br>
    <br>
    <br>
  </body>
</html>

--------------000804020106070503000006--