=?ISO-8859-2?Q?Piotr_Gasid=B3o?= <quaker@xxxxxxxxxxxxxx> 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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly
