Re: [HACKERS] Not enough memory for complex join

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: [HACKERS] Not enough memory for complex join
Дата
Msg-id Pine.BSF.4.05.9903051341220.7045-100000@thelab.hub.org
обсуждение исходный текст
Ответ на Re: [HACKERS] Not enough memory for complex join  (Oleg Broytmann <phd@sun.med.ru>)
Ответы Re: [HACKERS] Not enough memory for complex join  (Oleg Broytmann <phd@sun.med.ru>)
Список 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 по дате отправления:

Предыдущее
От: Oleg Broytmann
Дата:
Сообщение: Greek locale
Следующее
От: "Jackson, DeJuan"
Дата:
Сообщение: PL/PGSQL