Re: *_collapse_limit, geqo_threshold

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Dimitri Fontaine" <dfontaine(at)hi-media(dot)com>
Cc: "Dimitri Fontaine" <dim(at)hi-media(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: *_collapse_limit, geqo_threshold
Date: 2009-07-10 17:28:29
Message-ID: 4A5733ED02000025000286A0@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> 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.

Actually, if we were going to add fine-grained optimizer hints for
this (which I'm not at all convinced is a good idea), I'd be tempted
to go with what I saw a few years ago in SAP-DB (later rebranded as
MySQL Max-DB): treat parentheses around JOIN operations as optimizer
hints. I would only consider this as remotely sane if there was an
enable_* GUC to disable the normal reordering of joins. It introduces
no new keywords. The queries are still standard compliant. We would
just have a configuration option which treats an optional part of the
standard syntax as a hint.

In other words:

select * from (t1 join t2 on <whatever>) join t3 on <whatever>;

would limit optimizer choice from those available with:

select * from t1 join t2 on <whatever> join t3 on <whatever>;

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-10 17:52:20 Re: *_collapse_limit, geqo_threshold
Previous Message Jaime Casanova 2009-07-10 17:23:47 Re: Lock Wait Statistics (next commitfest)