Re: [GENERAL] Equivalence Classes when using IN
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] Equivalence Classes when using IN |
Дата | |
Msg-id | 12778.1507557092@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [GENERAL] Equivalence Classes when using IN (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [GENERAL] Equivalence Classes when using IN
Re: [GENERAL] Equivalence Classes when using IN |
Список | pgsql-general |
David Rowley <david.rowley@2ndquadrant.com> writes: > It's not all that clear what your view is doing here. Confusingly > there's a Sort in the plan, yet nothing in the query asked for that, > so I guess that the view must have an ORDER BY. If you get rid of that > the planner would likely use an index on product (customer_id) to > parameterise the nested loop, at least, it likely would, if you have > one. Yeah. The ORDER BY creates a partial optimization fence, preventing any such plan from being considered. > It's pretty bad practice to have ORDER BY in views. I kinda wish we > didn't even allow it, but that ship sailed many years ago... I think it's actually disallowed by the SQL spec (although so are many other things we support). IMO it's a useful facility to have for views that are meant for direct presentation to clients --- but if you'd like joins to the view to be optimized, you don't want an ORDER BY in there. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
В списке pgsql-general по дате отправления: