Re: A Better Way? (Multi-Left Join Lookup)
От
Tom Lane
Тема
Re: A Better Way? (Multi-Left Join Lookup)
Дата
Msg-id
21258.1342892175@sss.pgh.pa.us
Ответ на
Re: A Better Way? (Multi-Left Join Lookup) (David Johnston)
Список
Дерево обсуждения
A Better Way? (Multi-Left Join Lookup) "David Johnston" <polobo@yahoo.com>
Re: A Better Way? (Multi-Left Join Lookup) Tom Lane <tgl@sss.pgh.pa.us>
Re: A Better Way? (Multi-Left Join Lookup) "David Johnston" <polobo@yahoo.com>
Re: A Better Way? (Multi-Left Join Lookup) Tom Lane <tgl@sss.pgh.pa.us>
Re: A Better Way? (Multi-Left Join Lookup) "David Johnston" <polobo@yahoo.com>
Re: A Better Way? (Multi-Left Join Lookup) Tom Lane <tgl@sss.pgh.pa.us>
Re: A Better Way? (Multi-Left Join Lookup) Tom Lane <tgl@sss.pgh.pa.us>
Re: A Better Way? (Multi-Left Join Lookup) "David Johnston" <polobo@yahoo.com>
Re: A Better Way? (Multi-Left Join Lookup) Alban Hertroys <haramrae@gmail.com>
Re: A Better Way? (Multi-Left Join Lookup) "David Johnston" <polobo@yahoo.com>
"David Johnston" writes: > So, > EXPLAIN SELECT function_call(...) -- yields a planner expectation of 1 row > [Whereas] > EXPLAIN SELECT * FROM function_call(...) -- yields a planner expectation of > "result_rows" which defaults to 1000 Hm ... > Was this an intentional design decision to override the result_rows estimate > of the function if it is used in the select list? Not so much an intentional decision as just that nobody ever did anything about it. In general, SRFs in the target list are considered a legacy feature, which we're going to deprecate as soon as we have LATERAL so that there's a better-defined substitute. So I'd not want to expend a lot of work on this. But it probably would be possible to extract the row count estimates nearly for free while extracting the target list's cost estimate, which we already have to make a pass over the expressions for. Let me go look at that ... regards, tom lane
В списке pgsql-general по дате отправления
От: Craig Ringer
Дата: