mirror of
https://github.com/postgres/postgres.git
synced 2026-03-03 13:51:00 -05:00
6d2c8c0e2a
We can detect whether the planner top level is going to care at all about cheap startup cost (it will only do so if query_planner's tuple_fraction argument is greater than zero). If it isn't, we might as well discard paths immediately whose only advantage over others is cheap startup cost. This turns out to get rid of quite a lot of paths in complex queries --- I saw planner runtime reduction of more than a third on one large query. Since add_path isn't currently passed the PlannerInfo "root", the easiest way to tell it whether to do this was to add a bool flag to RelOptInfo. That's a bit redundant, since all relations in a given query level will have the same setting. But in the future it's possible that we'd refine the control decision to work on a per-relation basis, so this seems like a good arrangement anyway. Per my suggestion of a few months ago. |
||
|---|---|---|
| .. | ||
| backend | ||
| bin | ||
| include | ||
| interfaces | ||
| makefiles | ||
| pl | ||
| port | ||
| template | ||
| test | ||
| timezone | ||
| tools | ||
| tutorial | ||
| .gitignore | ||
| bcc32.mak | ||
| DEVELOPERS | ||
| Makefile | ||
| Makefile.global.in | ||
| Makefile.shlib | ||
| nls-global.mk | ||
| win32.mak | ||