Re: New hashed IN code ignores distinctiveness of subquery

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: New hashed IN code ignores distinctiveness of subquery
Дата
Msg-id 19654.1043643608@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: New hashed IN code ignores distinctiveness of subquery  (Bradley Baetz <bbaetz@acm.org>)
Список pgsql-bugs
Bradley Baetz <bbaetz@acm.org> writes:
> By cached, do you mean PREPARE stuff, or something else?

PREPARE, and cached plans in plpgsql, and cached plans in SPI, and
cached plans for foreign keys (though probably those never use IN)
and perhaps other places I'm not thinking of at the moment.

> However, its much faster (although not as fast as sticking the DISTINCT
> in there myself), but the actual rows coming from the sort is really odd
> - where is that number coming from? How can sorting 9 rows take 44476
> anythings?

We're back full circle to my original comment about rescans in
mergejoin.  The EXPLAIN ANALYZE instrumentation counts a re-fetch
as another returned row.

            regards, tom lane

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

Предыдущее
От: Bradley Baetz
Дата:
Сообщение: Re: New hashed IN code ignores distinctiveness of subquery
Следующее
От: "Key88 SF"
Дата:
Сообщение: Cursor case-sensitivity