{"push_id":1684328685,"size":1,"distinct_size":1,"ref":"refs/heads/REL9_5_STABLE","head":"6f0f98bb0bced134c09b7acf8fe35ff3a6f1bbd2","before":"b6e6ae1dc6a647ae6c846c79a8515802a29ebaba","commits":[{"sha":"6f0f98bb0bced134c09b7acf8fe35ff3a6f1bbd2","author":{"name":"Tom Lane","email":"9ca635a44fdf5aa326758d8d245579b9ae84653c@sss.pgh.pa.us"},"message":"Always build a custom plan node's targetlist from the path's pathtarget.\n\nWe were applying the use_physical_tlist optimization to all relation\nscan plans, even those implemented by custom scan providers.  However,\nthat's a bad idea for a couple of reasons.  The custom provider might\nbe unable to provide columns that it hadn't expected to be asked for\n(for example, the custom scan might depend on an index-only scan).\nEven more to the point, there's no good reason to suppose that this\n\"optimization\" is a win for a custom scan; whatever the custom provider\nis doing is likely not based on simply returning physical heap tuples.\n(As a counterexample, if the custom scan is an interface to a column store,\ndemanding all columns would be a huge loss.)  If it is a win, the custom\nprovider could make that decision for itself and insert a suitable\npathtarget into the path, anyway.\n\nPer discussion with Dmitry Ivanov.  Back-patch to 9.5 where custom scan\nsupport was introduced.  The argument that the custom provider can adjust\nthe behavior by changing the pathtarget only applies to 9.6+, but on\nbalance it seems more likely that use_physical_tlist will hurt custom\nscans than help them.\n\nDiscussion: https://postgr.es/m/e29ddd30-8ef9-4da5-a50b-2bb7b8c7198d@postgrespro.ru","distinct":true,"url":"https://api.github.com/repos/postgres/postgres/commits/6f0f98bb0bced134c09b7acf8fe35ff3a6f1bbd2"}]}
{"actor":{"display_login":"postgres-mirror"}}