Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id B23639F9C75 for ; Tue, 28 Aug 2007 23:45:16 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 14465-01-6 for ; Tue, 28 Aug 2007 23:45:05 -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.228]) by postgresql.org (Postfix) with ESMTP id 740009F9C3A for ; Tue, 28 Aug 2007 23:45:11 -0300 (ADT) Received: by wx-out-0506.google.com with SMTP id r21so43956wxc for ; Tue, 28 Aug 2007 19:45:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=mK3SbFq3O7EVzKER+FqkVMg5bFE7vnnkzT0LacOCiXGBJLvCdbHwsATcvShvPv6ZodUhiG4i9QPdtsZlfVLaq5XFuReW67PV8B5CfThWZCLtnwYOYktI9z/eSGwHyZtgKxSyhdMAk10NWtmTXvSWyPWjiRwCFIPwjdaR5HM/EE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=gwlrqMhxpGJ85NEZGn7IV0Oz5WMZaXkjc0X86P5QNsCR7WJyONAV/jamha9JgmcyHO42DL+1MRLs8bhXvdApfmYi2XVTO+Lr7+0qQvjfM9umiKI/gNhgANQhxC/rcEEGPgJzGnRj2xn42lDFTN/NlzHJjAB2fl9sjB/GxMK/+bA= Received: by 10.90.99.20 with SMTP id w20mr1698641agb.1188355510001; Tue, 28 Aug 2007 19:45:10 -0700 (PDT) Received: by 10.90.116.9 with HTTP; Tue, 28 Aug 2007 19:45:09 -0700 (PDT) Message-ID: <36af4bed0708281945o62e4fa58r9ec30b505fb779f8@mail.gmail.com> Date: Wed, 29 Aug 2007 08:15:09 +0530 From: Robins Reply-To: robins@pobox.com To: pgsql-performance@postgresql.org Subject: Re: Performance across multiple schemas In-Reply-To: <36af4bed0708281850v5348da17y97b7df2e696262e9@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_101256_31287907.1188355509949" References: <36af4bed0708280605j5448ac52of6f7dc08791f0ab2@mail.gmail.com> <23414.1188308966@sss.pgh.pa.us> <36af4bed0708281850v5348da17y97b7df2e696262e9@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200708/370 X-Sequence-Number: 26500 ------=_Part_101256_31287907.1188355509949 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/29/07, Robins Tharakan wrote: > > 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 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 > > -- Robins ------=_Part_101256_31287907.1188355509949 Content-Type: text/html; 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/29/07, Robins Tharakan <robins@pobox.com> wrote:
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



--
Robins ------=_Part_101256_31287907.1188355509949--