| От | Tom Lane |
|---|---|
| Тема | Re: Why would this slow the query down so much? |
| Дата | |
| Msg-id | 14373.1003158756@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Why would this slow the query down so much? (Stuart Grimshaw <nospam@smgsystems.co.uk>) |
| Ответы |
Re: Why would this slow the query down so much?
|
| Список | pgsql-sql |
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?
regards, tom lane
В списке pgsql-sql по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера