mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-27 03:27:19 +02:00
3b0f77601b
add_path_precheck was doing exact comparisons of path costs, but it really
needs to do them fuzzily to be sure it won't reject paths that could
survive add_path's comparisons. (This can only matter if the initial cost
estimate is very close to the final one, but that turns out to often be
true.)
Also, it should ignore startup cost for this purpose if and only if
compare_path_costs_fuzzily would do so. The previous coding always ignored
startup cost for parameterized paths, which is wrong as of commit
3f59be836c555fa6; it could result in improper early rejection of paths that
we care about for SEMI/ANTI joins. It also always considered startup cost
for unparameterized paths, which is just as wrong though the only effect is
to waste planner cycles on paths that can't survive. Instead, it should
consider startup cost only when directed to by the consider_startup/
consider_param_startup relation flags.
Likewise, compare_path_costs_fuzzily should have symmetrical behavior
for parameterized and unparameterized paths. In this case, the best
answer seems to be that after establishing that total costs are fuzzily
equal, we should compare startup costs whether or not the consider_xxx
flags are on. That is what it's always done for unparameterized paths,
so let's make the behavior for parameterized paths match.
These issues were noted while developing the SEMI/ANTI join costing fix
of commit
|
||
---|---|---|
.. | ||
data | ||
expected | ||
input | ||
output | ||
sql | ||
.gitignore | ||
GNUmakefile | ||
Makefile | ||
parallel_schedule | ||
pg_regress_main.c | ||
pg_regress.c | ||
pg_regress.h | ||
README | ||
regress.c | ||
regressplans.sh | ||
resultmap | ||
serial_schedule | ||
standby_schedule |
Documentation concerning how to run these regression tests and interpret the results can be found in the PostgreSQL manual, in the chapter "Regression Tests".