Re: [HACKERS] Possible problem in Custom Scan API
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Possible problem in Custom Scan API |
Дата | |
Msg-id | 29429.1492457615@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Possible problem in Custom Scan API (Dmitry Ivanov <d.ivanov@postgrespro.ru>) |
Ответы |
Re: [HACKERS] Possible problem in Custom Scan API
|
Список | pgsql-hackers |
Dmitry Ivanov <d.ivanov@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
В списке pgsql-hackers по дате отправления: