Re: *_collapse_limit, geqo_threshold

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Dimitri Fontaine <dim(at)hi-media(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: *_collapse_limit, geqo_threshold
Date: 2009-07-10 16:48:48
Message-ID: 51E5271C-8294-4F77-8F5D-A16D867B50E3@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-10 17:06:11 Re: *_collapse_limit, geqo_threshold
Previous Message Stefan Kaltenbrunner 2009-07-10 16:35:56 Re: Launching commitfest.postgresql.org