Re: two seperate queries run faster than queries ORed together
В списке pgsql-performance по дате отправления:
| От | Joseph Shraibman |
|---|---|
| Тема | Re: two seperate queries run faster than queries ORed together |
| Дата | |
| Msg-id | 405F37CE.9070302@selectacast.net обсуждение исходный текст |
| Ответ на | Re: two seperate queries run faster than queries ORed together (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: two seperate queries run faster than queries ORed
|
| Список | pgsql-performance |
Tom Lane wrote: > Joseph Shraibman <jks@selectacast.net> writes: > >>No, pkey is not the primary key in this case. The number of entries in u >>that have pkey 260 and not boolfield is 344706. > > > ... and every one of those rows *must* be included in the join input, *If* you use one big join in the first place. If postgres ran the query to first get the values with status == 3 from u, then ran the query to get the entries from d, then combined them, the result would be the same but the output faster. Instead it is doing seq scans on both tables and doing an expensive join that returns only a few rows.
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера