Re: Query too slow

Поиск
Список
Период
Сортировка
Искать
От
Shridhar Daithankar
Тема
Re: Query too slow
Дата
Msg-id
3F4A8811.17912.54E46A0@localhost
Ответ на
Re: Query too slow (Stephan Szabo)
Список
Дерево обсуждения
Query too slow Rhaoni Chiu Pereira <rhaoni@sistemica.info>
Re: Query too slow Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: Query too slow "Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>
Re: Query too slow Ang Chin Han <angch@bytecraft.com.my>
Re: Query too slow Stephan Szabo <sszabo@megazone.bigpanda.com>
Re: Query too slow Tom Lane <tgl@sss.pgh.pa.us>
Re: Query too slow Bruce Momjian <pgman@candle.pha.pa.us>
Re: Query too slow Bruce Momjian <pgman@candle.pha.pa.us>
On 25 Aug 2003 at 8:44, Stephan Szabo wrote:

> On Mon, 25 Aug 2003, Rhaoni Chiu Pereira wrote:
> 
> > Hi List,
> >
> >      As I said before, I'm not a DBA " yet" , but I'm learning ... and I
> > already have a PostgreSQL running, so I have to ask some help...
> >       I got a SQL as folows :
> 
> ...
> 
> Looking at the explain:
> 
> It's choosing lots of nested loops because it's expecting a small number
> of rows to be returned at each step but in reality there are alot of rows
> so that's may not really be a good choice.
> 
> For example the scan of ftnfco00 is expected to return 295 rows but
> actually returns 9339, and it looks like it's not estimating the number of
> matches between the tables very well either since the real count gets up
> to 240000 in a step where the estimated rows goes to 1.
> 
> What does explain analyze give after set enable_nestloop=off;?

In addition to that if it is getting the stats wrong, does running vacuum 
analyze help? If stats are updated, it should pick up proper plans, right?

Bye
 Shridhar

--
Flon's Law:	There is not now, and never will be, a language in	which it is the 
least bit difficult to write bad programs.

В списке pgsql-performance по дате отправления
От: Stephan Szabo
Дата:
Сообщение: Re: Query too slow
От: Bupp Phillips
Дата:
FAQ