Re: two seperate queries run faster than queries ORed together

Поиск
Список
Период
Сортировка
От Joseph Shraibman
Тема Re: two seperate queries run faster than queries ORed together
Дата
Msg-id 405F4114.5070602@selectacast.net
обсуждение исходный текст
Ответ на Re: two seperate queries run faster than queries ORed  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Список pgsql-performance
Stephan Szabo wrote:
> On Mon, 22 Mar 2004, Joseph Shraibman wrote:
>
>
>>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
>
>
> Well, you have to be careful on the combination to not give the wrong
> answers if there's a row with u.status=3 that matches a row d.status=3.

Right you would have to avoid duplicates.  The existing DISTINCT code
should be able to handle that.

В списке pgsql-performance по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: two seperate queries run faster than queries ORed
Следующее
От: Tom Lane
Дата:
Сообщение: Re: two seperate queries run faster than queries ORed