Re: Plan weirdness. A sort produces more rows than the node beneath it

Поиск
Список
Период
Сортировка
От Dane Foster
Тема Re: Plan weirdness. A sort produces more rows than the node beneath it
Дата
Msg-id CA+Wxin+8NEuMCwYzdjV=Eb0uA1bNfqZGASznGKf9Bzwp0CiP-w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Plan weirdness. A sort produces more rows than the node beneath it  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Дерево обсуждения

Hmm.  The planner should avoid using a merge join if it knows that
to be true.  Maybe analyze'ing that table would prompt it to use
some other join method?


The planner has updated stats on the table and wants to use a nested loop:

https://explain.dalibo.com/plan/3814d5356cc82528


But the nested loop version is around 8 seconds slower so I forced the issue. But thanks to this conversation I now understand what's happening with the row count. This understanding helped make the nested loops' plan easier to understand. Unfortunately, there doesn't seem to be any hope for the merge join variant in terms of being easily understood. The uninitiated sees a scan node and its parent sort node and their brain defaults to thinking: the sort node will produce the same number of rows as the node feeding it.


Cheers,

Dane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Plan weirdness. A sort produces more rows than the node beneath it
Следующее
От: "An, Hongguo (CORP)"
Дата:
Сообщение: Function call very slow from JDBC/java but super fast from DBear