Re: *_collapse_limit, geqo_threshold

On Jul 10, 2009, at 11:48 AM, Dimitri Fontaine <dfontaine(at)hi-
media.com> wrote:

> Hi,
>
> Le 10 juil. 09 à 17:22, Robert Haas a écrit :
>> I took a look at this and it seems that #3 can be implemented with
>> essentially no additional code (the handful of lines I added where
>> more than balanced out by some simplifications in ruleutils.c). Of
>> course you still don't have to like it. :-)
>
> I see you're using the following syntax:
> ! SELECT * FROM a INNER FORCE JOIN (b INNER FORCE JOIN c ON (b.ref =
> c.id)) ON (a.id = b.id);
>
> The only place I've seen that before is MySQL straight_join feature:
> http://dev.mysql.com/doc/refman/5.0/en/join.html
>
> My first though at the time was "what a lame optimiser if I'm to
> tell it where not to reorder joins", but perhaps this was because
> the option there, IIRC, could impact the results...
>
> I guess I'm not going to like it, but nonetheless, if we're going to
> support the feature, what about calling it the same as MySQL, unless
> the standard has something to say?

Well, I think we would be well-advised to get past the threshold issue
of whether or not the overall design sucks before quibbling over
details like my particular choice of keyword. That having been said,
if the MySQL feature to which you linked actually does the same thing
as what I implemented here, then it's amazingly poorly documented. We
certainly don't guarantee anything about the order in which the input
tables are read; I'd ask what that even means except I don't care.
We're only making a promise about where that join will be implemented
in the plan tree as compared with *other joins*.

It was reported upthread that Oracle uses ORDERED for this but I don't
know whether either the syntax or the semantics match what I did
here. At any rate the particular choice of keyword seems rather
insignificant; I picked it because it was already a keyword and seemed
vaguely appropriate, but it could easily be changed.

...Robert