aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistget.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-04-17 15:29:00 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2017-04-17 15:29:00 -0400
commit6f0f98bb0bced134c09b7acf8fe35ff3a6f1bbd2 (patch)
treea61a2a9da76050a9a134f8a492b152d24d5fd6b3 /src/backend/access/gist/gistget.c
parentb6e6ae1dc6a647ae6c846c79a8515802a29ebaba (diff)
downloadpostgresql-6f0f98bb0bced134c09b7acf8fe35ff3a6f1bbd2.tar.gz
postgresql-6f0f98bb0bced134c09b7acf8fe35ff3a6f1bbd2.zip
Always build a custom plan node's targetlist from the path's pathtarget.
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
Diffstat (limited to 'src/backend/access/gist/gistget.c')
0 files changed, 0 insertions, 0 deletions