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