mirror of
https://github.com/postgres/postgres.git
synced 2026-02-25 10:50:50 -05:00
6c73b390b4
We were applying the use_physical_tlist optimization to all relation scan plans, even those implemented by custom scan providers. However, that's a bad idea for a couple of reasons. The custom provider might be unable to provide columns that it hadn't expected to be asked for (for example, the custom scan might depend on an index-only scan). Even more to the point, there's no good reason to suppose that this "optimization" is a win for a custom scan; whatever the custom provider is doing is likely not based on simply returning physical heap tuples. (As a counterexample, if the custom scan is an interface to a column store, demanding all columns would be a huge loss.) If it is a win, the custom provider could make that decision for itself and insert a suitable pathtarget into the path, anyway. Per discussion with Dmitry Ivanov. Back-patch to 9.5 where custom scan support was introduced. The argument that the custom provider can adjust the behavior by changing the pathtarget only applies to 9.6+, but on balance it seems more likely that use_physical_tlist will hurt custom scans than help them. Discussion: https://postgr.es/m/e29ddd30-8ef9-4da5-a50b-2bb7b8c7198d@postgrespro.ru |
||
|---|---|---|
| .. | ||
| access | ||
| bootstrap | ||
| catalog | ||
| commands | ||
| executor | ||
| foreign | ||
| lib | ||
| libpq | ||
| main | ||
| nodes | ||
| optimizer | ||
| parser | ||
| po | ||
| port | ||
| postmaster | ||
| regex | ||
| replication | ||
| rewrite | ||
| snowball | ||
| storage | ||
| tcop | ||
| tsearch | ||
| utils | ||
| .gitignore | ||
| common.mk | ||
| Makefile | ||
| nls.mk | ||