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. It's *the core code* that builds the targetlist, and sometimes it may decide to provide a physical targetlist, not the one that's *really needed*. The broader targetlist has Vars that cannot be supplied by the IndexOnlyScan node, hence the error.

We cannot come up with our own targetlist because we don't know if it's a top node and we should return exactly the same tuple (CP_EXACT_TLIST) or it's just the stray optimization that made us think so.

Append works only because it doesn't allow projections, and it can never get a physical targetlist if an index doesn't contain all columns.

But everything changes when we use CustomScan: PostgreSQL will not pay attention. For example, if our CustomScan is a child of NestLoop, the former will call this (create_nestloop_plan):

inner_plan = create_plan_recurse(root, best_path->innerjoinpath, 0);

Since NestLoop can make projections, it doesn't enforce CP_EXACT_TLIST flag, and our CustomScan may end up with a full physical targetlist (see the code of create_scan_plan() if you don't believe me), INSTEAD OF the one it really has been asked to produce. Meanwhile, Append will behave as it should, since it doesn't care about physical tlists.

It's not just my imagination.

Dmitry Ivanov
Postgres Professional:
Russian Postgres Company

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to