Thread: improve join_collapse_limit docs

improve join_collapse_limit docs

From
Neil Conway
Date:
This patch makes some improvements to the SGML documentation for the
join_collapse_limit GUC var, as well as fixing two instances of some
missing SGML markup.

Any additional suggestions for improvement to the changes I've made
are welcome. I'm not entirely satisfied with the new text, but it's a
significant improvement IMHO.

-Neil

Attachment

Re: improve join_collapse_limit docs

From
Tom Lane
Date:
Mostly nit-picking, but for what it's worth:

Neil Conway <neilc@samurai.com> writes:
> !         <note>
> !          <para>
> !           The order of outer joins specified via the <literal>JOIN</>
> !           construct is never adjusted by the query planner; therefore,
> !           <varname>join_collapse_limit</> has no effect on this
> !           behavior.

This should include some weasel-wording along the lines of "At present,
blah blah blah".  It is theoretically legal to reorder outer joins in
some cases, and I harbor ambitions of teaching the planner about that
sooner or later.

> !         <varname>from_collapse_limit</varname>, which is appropriate
> !         for most users. Setting it to 1 prevents any reordering of

"most uses", perhaps ?

> !         order they desire explicitely. Another consequence of setting

spell-check ...

> !         this variable to 1 is that the query planner will behave more
> !         similarly to the <productname>PostgreSQL</productname> 7.3

"more similarly" is bad grammar ... try "more like the" ...

            regards, tom lane

Re: improve join_collapse_limit docs

From
Neil Conway
Date:
Tom Lane <tgl@sss.pgh.pa.us> writes:
> This should include some weasel-wording along the lines of "At
> present, blah blah blah".

Good point, thanks.

> It is theoretically legal to reorder outer joins in some cases

Indeed; see "Outerjoin Simplification and Reordering for Query
Optimization" by Gelindo-Legaria and Rosenthal (ACM TDS, Vol. 22,
No. 1, March 1997, Pages 43-74), for example.

> I harbor ambitions of teaching the planner about that sooner or
> later.

Indeed, I've speculated about doing this myself at some indeterminate
point in the future. Of course (a) your knowledge of the optimizer
dwarfs my own by several orders of magnitude (b) I don't have any firm
plans to do this, it just looked like an interesting problem. So
please don't let me stop you implementing this yourself at your
leisure.

I've fixed the other minor points you raised and applied the patch --
thanks for the feedback.

-Neil