Re: fool-toleranced optimizer

Simon Riggs wrote:
> Oleg is saying that the optimizer doesn't protect against foolish SQL
> requests. His query is an example of a foolishly written query.

IMHO calling this a "foolishly written query" is completely arbitrary. I
can imagine plenty of applications for which a cartesian join makes
sense. In this case the user didn't write the query they meant to write
-- but it is surely hopeless to prevent that in the general case :)

> It seems a reasonable that there might be a GUC such as
> enable_cartesian = on (by default)

I think the bar for adding a new GUC ought to be significantly higher
than that.

In any case, when this problem does occur, it is obvious to the user
that something is wrong, and no harm is done. Given a complex SQL query,
it might take a bit of examination to determine which join clause is
missing -- but the proper way to fix that is better query visualization
tools (perhaps similar RH's Visual Explain, for example). This would
solve the general problem: "the user didn't write the query they
intended to write", rather than a very narrow subset ("the user forgot a
join clause and accidentally computed a cartesian product").

-Neil