Re: Why would this slow the query down so much?
От | Masaru Sugawara |
---|---|
Тема | Re: Why would this slow the query down so much? |
Дата | |
Msg-id | 20011017215538.5D57.RK73@echna.ne.jp обсуждение исходный текст |
Ответ на | Re: Why would this slow the query down so much? (Stuart Grimshaw <stuart@smgsystems.co.uk>) |
Список | 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 по дате отправления: