Re: [HACKERS] Possible problem in Custom Scan API

Tom Lane wrote: 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. You're right, of course. Thank you very much! -- Dmitry Ivanov

Re: [HACKERS] Possible problem in Custom Scan API

Dmitry Ivanov 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

Re: [HACKERS] Possible problem in Custom Scan API

Tom Lane wrote: I'm coming around to the idea that it'd be better to disable physical tlists for custom scans. 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

Re: [HACKERS] Possible problem in Custom Scan API

Dmitry Ivanov writes: >> Uh, no, construction of a custom plan node is entirely driven by the >> PlanCustomPath method as far as I can see. You're free to ignore what >> create_scan_plan did and insert your own tlist. > Are you sure? Even if it's true, this targetlist

Re: [HACKERS] Possible problem in Custom Scan API

On Wed, Apr 12, 2017 at 12:59 AM, Dmitry Ivanov wrote: > Tom Lane wrote: > >> Uh, no, construction of a custom plan node is entirely driven by the >> PlanCustomPath method as far as I can see. You're free to ignore what >> create_scan_plan did and insert your own tlist.

Re: [HACKERS] Possible problem in Custom Scan API

Tom Lane wrote: Uh, no, construction of a custom plan node is entirely driven by the PlanCustomPath method as far as I can see. You're free to ignore what create_scan_plan did and insert your own tlist. Are you sure? Even if it's true, this targetlist should still contain each and every Var

Re: [HACKERS] Possible problem in Custom Scan API

Dmitry Ivanov writes: >> Reading between the lines, I think the problem may be that you're not >> being careful about how you set up custom_scan_tlist. But since the >> core code has zero involvement in that decision, it's hard to see why >> it would be a core code bug.

Re: [HACKERS] Possible problem in Custom Scan API

Tom Lane wrote: Reading between the lines, I think the problem may be that you're not being careful about how you set up custom_scan_tlist. But since the core code has zero involvement in that decision, it's hard to see why it would be a core code bug. I'm sorry, but you didn't understand.

Re: [HACKERS] Possible problem in Custom Scan API

Dmitry Ivanov writes: > Tom Lane wrote: >> Uh, why would you see that? The planner would never generate an >> IndexOnlyScan in the first place if the query required any columns >> not available from the index. > True, but as you can see, create_append_plan() produces

Re: [HACKERS] Possible problem in Custom Scan API

Tom Lane wrote: Uh, why would you see that? The planner would never generate an IndexOnlyScan in the first place if the query required any columns not available from the index. True, but as you can see, create_append_plan() produces its own targetlist: static Plan *

Re: [HACKERS] Possible problem in Custom Scan API

Dmitry Ivanov writes: > In theory, CustomScans should be able to use any Plan nodes (i.e. > 'custom_plans' list), but as far as I can understand, there's no way to > override behavior of use_physical_tlist(), which means that we might see > something like this: >

[HACKERS] Possible problem in Custom Scan API

Hi hackers, I'm struggling to understand one particular thing about Custom Scan API. As you may know, there's a function called use_physical_tlist(), which aims to eliminate meaningless projections during query execution. Any scan node (e.g. CustomScan) aims to take advantage of physical