Re: Equivalence Classes when using IN

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Kim Rose Carlsen <krc(at)hiper(dot)dk>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Equivalence Classes when using IN
Date: 2017-10-09 13:51:32
Message-ID: 12778.1507557092@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

David Rowley <david(dot)rowley(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Larry Rosenman 2017-10-09 13:51:59 Re: Using cp to back up a database?
Previous Message Ron Johnson 2017-10-09 13:40:46 Using cp to back up a database?