Re: two seperate queries run faster than queries ORed together
В списке pgsql-performance по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: two seperate queries run faster than queries ORed together |
| Дата | |
| Msg-id | 6875.1079979859@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: two seperate queries run faster than queries ORed together (Joseph Shraibman <jks@selectacast.net>) |
| Ответы |
Re: two seperate queries run faster than queries ORed together
|
| Список | pgsql-performance |
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,
regardless of its status value, because it might join to some d row that
has status=3. Conversely, every single row of d must be considered in
the join because it might join to some u row with status=3. So any way
you slice it, this query requires a large and expensive join operation,
no matter that there are only a few rows with the right status values in
the other table.
I'd rewrite the query if I were you.
regards, tom lane
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера