From: Dmitry Ivanov <d.ivanov@postgrespro.ru>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Possible problem in Custom Scan API
Date: Tue, 11 Apr 2017 19:36:11 +0300
MIME-Version: 1.0
Message-ID: <e29ddd30-8ef9-4da5-a50b-2bb7b8c7198d@postgrespro.ru>
Organization: Postgres Professional
User-Agent: Trojita/0.7; Qt/5.8.0; xcb; Linux; 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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=
=20
to eliminate meaningless projections during query execution. Any scan node=
=20
(e.g. CustomScan) aims to take advantage of physical targetlists... except=
=20
for the IndexOnlyScan (for obvious reasons):

createplan.c, create_scan_plan():

if (use_physical_tlist(root, best_path, flags))
{
	if (best_path->pathtype =3D=3D T_IndexOnlyScan)
	{
		/* For index-only scan, the preferred tlist is the index's */
		tlist =3D copyObject(((IndexPath *) best_path)->indexinfo->indextlist);
		...
	}
...
}

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

ERROR:  variable not found in subplan target list

if we use child IndexOnlyScan and the index does not include some of the=20
relation's columns.

Is there any existing workaround?


--=20
Dmitry Ivanov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers