Dmitry Ivanov <d.iva...@postgrespro.ru> writes:
> Tom Lane wrote:
>> I'm coming around to the idea that it'd be better to disable physical
>> tlists for custom scans.
>> However, I'm hesitant to make such a change in the back branches; if
>> there's anyone using custom scans who's negatively affected, they'd be
>> rightfully unhappy. Are you satisfied if we change this in HEAD?
After thinking about this over the weekend, I've come to the conclusion
that back-patching is probably the right thing anyway. The upside of the
use_physical_tlist optimization is pretty marginal even when it applies,
while the downsides of applying it inappropriately can be very large,
as we've discussed.
> I've been thinking about this all along, and it seems that this is a decent
> decision. However, I've made a tiny bugfix patch which allows CustomScans
> to notify the core code that they can handle physical targetlists.
I'm unimpressed by this part --- we couldn't back-patch such a change, and
I think it's unnecessary anyway in 9.6+ because the scan provider could
generate a nondefault pathtarget if it wants this to happen.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
