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.
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.
> 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
In response to
pgsql-performance by date
|Next:||From: Paul||Date: 2007-08-29 08:16:45|
|Subject: Re: index & Bitmap Heap Scan|
|Previous:||From: Robins Tharakan||Date: 2007-08-29 01:50:51|
|Subject: Re: Performance across multiple schemas|