Re: Possible problem in Custom Scan API

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

In response to

Responses

Browse pgsql-hackers by date

  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