From: | Robins <tharakan(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Performance across multiple schemas |
Date: | 2007-08-29 02:45:09 |
Message-ID: | 36af4bed0708281945o62e4fa58r9ec30b505fb779f8@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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(at)pobox(dot)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(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Paul | 2007-08-29 08:16:45 | Re: index & Bitmap Heap Scan |
Previous Message | Robins Tharakan | 2007-08-29 01:50:51 | Re: Performance across multiple schemas |