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)
Список
Дерево обсуждения
[GENERAL] Equivalence Classes when using IN Kim Rose Carlsen <krc@hiper.dk>
Re: [GENERAL] Equivalence Classes when using IN David Rowley <david.rowley@2ndquadrant.com>
Re: [GENERAL] Equivalence Classes when using IN Tom Lane <tgl@sss.pgh.pa.us>
Re: [GENERAL] Equivalence Classes when using IN Kim Rose Carlsen <krc@hiper.dk>
Re: [GENERAL] Equivalence Classes when using IN David Rowley <david.rowley@2ndquadrant.com>
Re: [GENERAL] Equivalence Classes when using IN Tom Lane <tgl@sss.pgh.pa.us>
Re: [GENERAL] Equivalence Classes when using IN Kim Rose Carlsen <krc@hiper.dk>
Re: [GENERAL] Equivalence Classes when using IN David Rowley <david.rowley@2ndquadrant.com>
Re: [GENERAL] Equivalence Classes when using IN Kim Rose Carlsen <krc@hiper.dk>
Re: [GENERAL] Equivalence Classes when using IN David Rowley <david.rowley@2ndquadrant.com>
Re: [GENERAL] Equivalence Classes when using IN David Rowley <david.rowley@2ndquadrant.com>
Re: [GENERAL] Equivalence Classes when using IN Tom Lane <tgl@sss.pgh.pa.us>
Re: [GENERAL] Equivalence Classes when using IN Nico Williams <nico@cryptonector.com>
Re: [GENERAL] Equivalence Classes when using IN David Rowley <david.rowley@2ndquadrant.com>
Re: [GENERAL] Equivalence Classes when using IN Kim Rose Carlsen <krc@hiper.dk>
Re: [GENERAL] Equivalence Classes when using IN Kim Rose Carlsen <krc@hiper.dk>
David Rowley 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 по дате отправления