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
|
Список | 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 по дате отправления: