Re: query speed depends on lifetime of frozen db? - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: query speed depends on lifetime of frozen db?
Date
Msg-id 20020928020558.GA28628@svana.org
Whole thread Raw
In response to Re: query speed depends on lifetime of frozen db?  (Andriy Tkachuk <ant@imt.com.ua>)
List pgsql-general
On Fri, Sep 27, 2002 at 05:58:05PM +0300, Andriy Tkachuk wrote:
> On Fri, 27 Sep 2002, Martijn van Oosterhout wrote:
>
> > On Fri, Sep 27, 2002 at 01:28:13PM +0300, Andriy Tkachuk wrote:
> > > On Fri, 27 Sep 2002, Martijn van Oosterhout wrote:
> > > > What is the output of EXPLAIN ANALYSE <query>;
> > >
> > > There is EXPLAIN ANALYSE when query is heavy:
> >
> > Oookaaay. Your query is *evil*. 14 subqueries executed for *each* row of
> > output!?! I reackon you could improve your query just by rewriting it into a
> > better form. How can you have 10 subqueries to the same table?
>
> YES! You right!
> Just after restirong db i made vacuumdb -z -f
> and query become heavy!
>
> Does one have any ideas how to ovecome this!?


Firstly, how is calc_account() defined? Is it doing subqueries? If it is
then the planner won't be seeing them. Is it optimised?

        calc_account (u.uid, 1030827600) as start_account,
        calc_account (u.uid, 1032178388) as end_account,

--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.

pgsql-general by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Performance while loading data and indexing
Next
From: Glen Baker
Date:
Subject: Re: 7.0 -> 7.2 Migration (oops)