From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Possible problem in Custom Scan API |
Date: | 2017-04-11 19:47:50 |
Message-ID: | 367.1491940070@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-04-11 19:52:34 | Re: TAP tests take a long time |
Previous Message | Robert Haas | 2017-04-11 19:17:09 | Re: Vacuum: allow usage of more than 1GB of work mem |