Re: *_collapse_limit, geqo_threshold - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: *_collapse_limit, geqo_threshold
Date
Msg-id 51E5271C-8294-4F77-8F5D-A16D867B50E3@hi-media.com
Whole thread Raw
In response to Re: *_collapse_limit, geqo_threshold  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: *_collapse_limit, geqo_threshold  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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?
--
dim

pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: [pgsql-www] Launching commitfest.postgresql.org
Next
From: Tom Lane
Date:
Subject: Re: *_collapse_limit, geqo_threshold