Received: from localhost (maia-4.hub.org [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 6B1939F9367
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 28 Aug 2007 22:50:58 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 03091-01 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Tue, 28 Aug 2007 22:50:53 -0300 (ADT)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5
Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236])
	by postgresql.org (Postfix) with ESMTP id E97F29FB5BB
	for <pgsql-performance@postgresql.org>;
	Tue, 28 Aug 2007 22:50:52 -0300 (ADT)
Received: by wx-out-0506.google.com with SMTP id r21so33880wxc
	for <pgsql-performance@postgresql.org>;
	Tue, 28 Aug 2007 18:50:51 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta;
	h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
	b=kT5ywxDqsmIqaKCEYtg9vJODvE6TpviGt2F4CIsul/XxMehpoaOVvqthJDnAkTwsj+1pZbHSeO2TV1XeqG5IKsHD74mgLboKPUBjVx/nEM9FbGkDoU+K/Snjwr3EnOV75CbAwxGjK+hPv8LH3uQ/EDoxrmIL39MlCXJsEMo2SFU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
	b=PobVCc9dfqnAteZRZn/2SR18WIpBdJzComkDqzdCRsP2wVCJX1/VDqDHtLiwXbQSvJqbZ9GaF9qPkbCBcQLMp5lRDifIwdJ8B7luSxHWUJp5u8y4nW/rbkPKBPy8eh8tPLNpXKZrzVJW5ACa1zRGdTsBu4sh85txe401RbUVX3w=
Received: by 10.90.28.13 with SMTP id b13mr1722305agb.1188352251615;
	Tue, 28 Aug 2007 18:50:51 -0700 (PDT)
Received: by 10.90.116.9 with HTTP; Tue, 28 Aug 2007 18:50:51 -0700 (PDT)
Message-ID: <36af4bed0708281850v5348da17y97b7df2e696262e9@mail.gmail.com>
Date: Wed, 29 Aug 2007 07:20:51 +0530
From: "Robins Tharakan" <robins@pobox.com>
To: pgsql-performance@postgresql.org
Subject: Re: Performance across multiple schemas
In-Reply-To: <23414.1188308966@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_100663_15537536.1188352251577"
References: <36af4bed0708280605j5448ac52of6f7dc08791f0ab2@mail.gmail.com>
	<23414.1188308966@sss.pgh.pa.us>
X-Google-Sender-Auth: b67dcc8bbe73f6fd
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200708/379
X-Sequence-Number: 26509

------=_Part_100663_15537536.1188352251577
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks Tom,

Exactly what I did, when I realised that there was an extra Table in the
FROM with no conditions set.

Well anyway, this did clear my doubts about whether schema affects
performance at all.

Robins

On 8/28/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>
> Schemas are utterly, utterly irrelevant to performance.
>
> I'm guessing you missed analyzing one of the tables, or forgot an index,
> or something like that.  Also, if you did anything "cute" like use the
> same table name in more than one schema, you need to check the
> possibility that some query is selecting the wrong one of the tables.
>
> The explain output you showed is no help because the expense is
> evidently down inside one of the functions in the SELECT output list.
>
> One thing you should probably try before getting too frantic is
> re-ANALYZEing all the tables and then starting a fresh session to
> clear any cached plans inside the functions.  If it's still slow
> then it'd be worth digging deeper.
>
>                         regards, tom lane

------=_Part_100663_15537536.1188352251577
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks Tom,<br><br>Exactly what I did, when I realised that there was an extra Table in the FROM with no conditions set.<br><br>Well anyway, this did clear my doubts about whether schema affects performance at all.<br><br>
<span style="font-weight: bold;">Robins</span><br><br><div><span class="gmail_quote">On 8/28/07, <b class="gmail_sendername">Tom Lane</b> &lt;<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Schemas are utterly, utterly irrelevant to performance.<br><br>I&#39;m guessing you missed analyzing one of the tables, or forgot an index,<br>or something like that.&nbsp;&nbsp;Also, if you did anything &quot;cute&quot; like use the
<br>same table name in more than one schema, you need to check the<br>possibility that some query is selecting the wrong one of the tables.<br><br>The explain output you showed is no help because the expense is<br>evidently down inside one of the functions in the SELECT output list.
<br><br>One thing you should probably try before getting too frantic is<br>re-ANALYZEing all the tables and then starting a fresh session to<br>clear any cached plans inside the functions.&nbsp;&nbsp;If it&#39;s still slow<br>then it&#39;d be worth digging deeper.
<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;regards, tom lane</blockquote></div>

------=_Part_100663_15537536.1188352251577--