From: | "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in> |
---|---|
To: | PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Query too slow |
Date: | 2003-08-25 16:35:05 |
Message-ID: | 3F4A8811.17912.54E46A0@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Travers | 2003-08-25 17:06:22 | Re: Replication Ideas |
Previous Message | Stephan Szabo | 2003-08-25 15:44:43 | Re: Query too slow |