Tom Lane wrote:
> Phil Endecott <spam_from_postgresql_general@chezphil.org> writes:
>
>>I have a number of complex views for which the typical use is to select
>>exactly one row by id, e.g. "select * from V where id=nnn". Some of
>>these selects run orders of magnitude faster than others. Looking at
>>the output of "explain analyse" it seems that in the fast cases the
>>"id=nnn" condition is passed down to the lower-level operations, while
>>in the slower cases the entire view is created and then filtered using
>>the condition as a final step.
>
> When in doubt, use the source ;-) ... most sorts of things like this are
> pretty well commented, if you can find the relevant code.
Good plan.
> * 3. If the subquery uses DISTINCT ON, we must not push down any quals that
> * refer to non-DISTINCT output columns, because that could change the set
> * of rows returned.
OK, so this is why my query with DISTINCT ON was failing. I can fix that.
I don't see anything in there about LEFT OUTER JOIN though. Any ideas?
--Phil.
