mirror of
https://github.com/zebrajr/postgres.git
synced 2025-12-07 12:20:31 +01:00
cac169d686
0.01 was unrealistically low as it's the same as the default cpu_tuple_cost and 10x cheaper than the default parallel_tuple_cost. It's hard to imagine a situation where fetching a tuple from a foreign server would be cheaper than fetching one from a parallel worker. After some experimentation on a loopback server, somewhere between 0.15 and 0.3 seems more realistic. Here we split the difference and set it to 0.2. This will cause operations that reduce the number of tuples (e.g. aggregation) to be more likely to take place on the foreign server. Adjusting this causes some plan changes in the postgres_fdw regression tests. This is because penalizing each Path with the additional tuple costs causes some dilution of the costs of the other operations being charged for and results in various paths appearing to be closer to the same costs such that add_path's STD_FUZZ_FACTOR is more likely to see two paths as costing (fuzzily) the same. This isn't ideal, but it shouldn't be reason enough to use artificially low costs. Discussion: https://postgr.es/m/CAApHDvopVjjfh5c1Ed2HRvDdfom2dEpMwwiu5-f1AnmYprJngA@mail.gmail.com |
||
|---|---|---|
| .. | ||
| expected | ||
| sql | ||
| .gitignore | ||
| connection.c | ||
| deparse.c | ||
| Makefile | ||
| meson.build | ||
| option.c | ||
| postgres_fdw--1.0--1.1.sql | ||
| postgres_fdw--1.0.sql | ||
| postgres_fdw.c | ||
| postgres_fdw.control | ||
| postgres_fdw.h | ||
| shippable.c | ||