=?ISO-8859-2?Q?Piotr_Gasid=B3o?= <quaker@barbara.eu.org> writes:
> I've just hit problem, that is unusual for me.
> View definition:
> SELECT users.id, users.user_name, users.extra IS NOT NULL AS has_extra
> FROM users;
What you've got here is a non-nullable target list, which creates an
optimization fence when used in the nullable side of an outer join.
The problem is that has_extra should read as NULL in the query output
for a sites_secure row that has no match in users_secure_with_has_extra,
but making users.extra go to null will not make that happen, so there's
a constraint on where the expression can be evaluated. The current
planner has no way to deal with that except by restricting the plan
structure.
We have some ideas about how to fix this, but don't hold your breath
... it's going to take major surgery on the planner, AFAICS.
regards, tom lane
