Re: Why does it sort rows after a nested loop that uses already-sorted indexes?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why does it sort rows after a nested loop that uses already-sorted indexes?
Дата
Msg-id 1825378.1713452017@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Why does it sort rows after a nested loop that uses already-sorted indexes?  (negora <public@negora.com>)
Ответы Re: Why does it sort rows after a nested loop that uses already-sorted indexes?  (negora <public@negora.com>)
Список pgsql-general
negora <public@negora.com> writes:
> As you can see, the planner does detect that the outer loop returns the 
> rows presorted by [sales_order.id]. However, it's unable to detect that 
> the rows returned by the inner loop are also sorted by [sales_order.id] 
> first, and then by [order_line.id].

That's a level of analysis that it doesn't do, and TBH I'm not even
entirely sure it's correct to assume that the output is sorted like
that.  At minimum you'd need an additional assumption that the
outer side's join key is unique, which is a factor that we don't
currently track when reasoning about ordering.

            regards, tom lane



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

Предыдущее
От: negora
Дата:
Сообщение: Why does it sort rows after a nested loop that uses already-sorted indexes?
Следующее
От: Michael Corey
Дата:
Сообщение: Foreign Key error between two partitioned tables