Re: [HACKERS] Possible problem in Custom Scan API - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Possible problem in Custom Scan API
Date
Msg-id 367.1491940070@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Possible problem in Custom Scan API  (Dmitry Ivanov <d.ivanov@postgrespro.ru>)
Responses Re: [HACKERS] Possible problem in Custom Scan API  (Dmitry Ivanov <d.ivanov@postgrespro.ru>)
List pgsql-hackers
Dmitry Ivanov <d.ivanov@postgrespro.ru> 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 its own targetlist:

> static Plan *
> create_append_plan(PlannerInfo *root, AppendPath *best_path)
> {
>     Append       *plan;
>     List       *tlist = build_path_tlist(root, &best_path->path);
>     ...

> If we replace Append with some custom node, the plan will instantly become 
> invalid (it won't be be able to build a projection from 'custom_scan_tlist' 
> to 'targetlist'). However, this doesn't mean that it's unable to produce 
> the same result.

You haven't really convinced me that anything is wrong there.  The append
plan's tlist isn't going to contain unwanted variables either.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] TAP tests take a long time