Re: Why would this slow the query down so much? - Mailing list pgsql-sql

From Masaru Sugawara
Subject Re: Why would this slow the query down so much?
Date
Msg-id 20011017215538.5D57.RK73@echna.ne.jp
Whole thread Raw
In response to Re: Why would this slow the query down so much?  (Stuart Grimshaw <stuart@smgsystems.co.uk>)
List pgsql-sql
On Tue, 16 Oct 2001 17:58:32 +0100
Stuart Grimshaw wrote:

> On Monday 15 October 2001 16:12 pm, Tom Lane wrote:
> > Stuart Grimshaw <nospam@smgsystems.co.uk> writes:
> > > SELECT a.category, b.headline, b.added, c.friendlyname
> > > FROM caturljoin as a
> > >         INNER JOIN stories as b ON (a.url = b.source)
> > >         INNER JOIN urllist as c ON (a.url = d.urn)
> > > WHERE a.category = 93 ORDER BY b.added DESC LIMIT 1;
> >
> > (I assume "d.urn" is a typo for "c.urn"...)
> >
> > The query plan you show looks pretty reasonable if the planner's row
> > count estimates are in the right ballpark.  How many caturljoin rows
> > have category = 93?  How many stories rows will match each caturljoin
> > row?  How many urllist rows ditto?
> 
> There are 194 rows in caturljoin where url = 93, 29806 rows in stories will 
> match those 194 rows and only 1 row in urllist will match.
> 
If it's convenient, would you try to delete some indices of the "stories" table?  the total number of sorts on theQUERY
PLANmight decrease.  However, this trial may be a vain effort. I can't expect the result of the QUERY PLAN.  :-)The
indices:"stories_source",             "stories_unique_story",             and "stories_urn_key"
 


Regards,
Masaru Sugawara



pgsql-sql by date:

Previous
From: "Steven Dahlin"
Date:
Subject: nvl() function
Next
From: Tom Lane
Date:
Subject: Re: Performance problems - Indexes and VACUUM