Re: [HACKERS] Not enough memory for complex join - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: [HACKERS] Not enough memory for complex join
Date
Msg-id Pine.BSF.4.05.9903051341220.7045-100000@thelab.hub.org
Whole thread Raw
In response to Re: [HACKERS] Not enough memory for complex join  (Oleg Broytmann <phd@sun.med.ru>)
Responses Re: [HACKERS] Not enough memory for complex join
List pgsql-hackers
On Fri, 5 Mar 1999, Oleg Broytmann wrote:

> Hi!
> 
> On Fri, 5 Mar 1999, Vadim Mikheev wrote:
> > Oleg Broytmann wrote:
> > > 
> > > Nested Loop  (cost=0.00 size=1 width=18)
> > >   ->  Nested Loop  (cost=0.00 size=1 width=14)
> > >         ->  Merge Join  (cost=0.00 size=1 width=10)
> > >               ->  Seq Scan  (cost=0.00 size=0 width=0)
> > >                     ->  Sort  (cost=0.00 size=0 width=0)
> > >                           ->  Seq Scan on districts d  (cost=0.00 size=0 width=4)
> > >               ->  Seq Scan  (cost=0.00 size=0 width=0)
> > >                     ->  Sort  (cost=0.00 size=0 width=0)
> > >                           ->  Seq Scan on shops sh  (cost=0.00 size=0 width=6)
> > >         ->  Seq Scan on central cn  (cost=0.00 size=0 width=4)
> > >   ->  Seq Scan on positions p  (cost=0.00 size=0 width=4)
> >                                             ^^^^^^
> > vacuum...
> 
>    I didn't think it could be of any help.  I have a copy of this database
> on my local computer. I dump db on server and put it on local computer
> every other day, so I thiink VACUUM is unneccessary here.

Try 'vacuum analyze'...vacuum, rom my understanding, just cleans out the
database of old records...reloading the db from scratch effectively has
that already done.  'vacuum analyze' adjusts statistics that don't get
changed on a load, that determins, to a large extet, how the optimizaer
runs things...

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



pgsql-hackers by date:

Previous
From: Oleg Broytmann
Date:
Subject: Greek locale
Next
From: "Jackson, DeJuan"
Date:
Subject: PL/PGSQL