Tom Lane wrote:
Phil Endecott <spam_from_postgresql_general@xxxxxxxxxxxx> 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.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
