Re: [GENERAL] Equivalence Classes when using IN - Mailing list pgsql-general

From Tom Lane
Subject Re: [GENERAL] Equivalence Classes when using IN
Date
Msg-id 12778.1507557092@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] Equivalence Classes when using IN  (David Rowley <david.rowley@2ndquadrant.com>)
Responses 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>)
List 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 by date:

Previous
From: Ron Johnson
Date:
Subject: [GENERAL] Using cp to back up a database?
Next
From: Larry Rosenman
Date:
Subject: Re: [GENERAL] Using cp to back up a database?