| From: | PG Doc comments form <noreply(at)postgresql(dot)org> |
|---|---|
| To: | pgsql-docs(at)lists(dot)postgresql(dot)org |
| Cc: | thomas(dot)bessou(at)hotmail(dot)fr |
| Subject: | Query planner documentation should mention xxx_collapse_limit parameters |
| Date: | 2022-06-30 16:15:51 |
| Message-ID: | 165660575172.671.12182908331636457344@wrigleys.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs |
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/14/git.html
Description:
We've spent days investigating a performance issue related to "explicit join
order"/"from_collapse_limit", where we would have expected a query using
"explicit join clauses" (we didn't know were named this way obviously, and
we are only using for ease-of-query-building purposes) to use the same plan
as a flat query.
During this time, we have naturally read the documentation at
https://www.postgresql.org/docs/current/planner-optimizer.html to see if it
would mention anything that would explain why these would behave
differently.
However, this documentation currently only says: "If the query uses fewer
than geqo_threshold relations, a near-exhaustive search is conducted to find
the best join sequence" (which we checked for), but does not mention the
explicit join behavior
(https://www.postgresql.org/docs/current/explicit-joins.html) nor the
from_collapse_limit or join_collapse_limit parameters.
(https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-FROM-COLLAPSE-LIMIT)
Mentioning these in a similar way as we explain geqo_threshold's possible
impact on query planning would be a huge improvement, and would have saved
us a lot of time.
Thanks,
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2022-07-05 19:48:44 | Re: proposal: convert comments in documents to html comments |
| Previous Message | PG Doc comments form | 2022-06-29 20:45:11 | How to reference the type of lock in the documentation. |