From: Dmitry Ivanov <d.ivanov@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dmitry Ivanov <d.ivanov@postgrespro.ru>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Possible problem in Custom Scan API
Date: Wed, 12 Apr 2017 00:59:16 +0300
MIME-Version: 1.0
Message-ID: <0e0388a6-aa53-42a6-8be9-0d46ccbc788e@postgrespro.ru>
In-Reply-To: <4509.1491944329@sss.pgh.pa.us>
References: <e29ddd30-8ef9-4da5-a50b-2bb7b8c7198d@postgrespro.ru>
 <20021.1491933424@sss.pgh.pa.us>
 <1ef85b46-1385-4810-bb80-97cd977da1d5@postgrespro.ru>
 <367.1491940070@sss.pgh.pa.us>
 <f7590622-182b-4362-b148-c21de109ad2a@postgrespro.ru>
 <4509.1491944329@sss.pgh.pa.us>
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

Tom Lane wrote:
> Uh, no, construction of a custom plan node is entirely driven by the
> PlanCustomPath method as far as I can see.  You're free to ignore what
> create_scan_plan did and insert your own tlist.

Are you sure? Even if it's true, this targetlist should still contain each=
=20
and every Var that's been requested. If I'm correct, the only way to ensure=
=20
that is to call build_path_tlist(), which is static (oops!). Perhaps I=20
could make my own, but it uses replace_nestloop_params() (again, static),=20
and the problem goes further and further.

This effectively means that it would be nice if I could just use the=20
existing machinery. The fix would be quite trivial.

By the way, what if our CustomScan is a top node? Let's take a look at=20
create_plan():

/* Recursively process the path tree, demanding the correct tlist result */
plan =3D create_plan_recurse(root, best_path, CP_EXACT_TLIST);

...
if (!IsA(plan, ModifyTable))
	apply_tlist_labeling(plan->targetlist, root->processed_tlist);
...

If I spoil the targetlist, everything blows up in apply_tlist_labeling():

Assert(list_length(dest_tlist) =3D=3D list_length(src_tlist));

since the lengths may differ. It's much safer to use the tlist provided by=
=20
the core code, but alas, sometimes it's not an option.

> In particular, if what
> your custom path actually is is a rescan of something like an
> IndexOnlyScan, why don't you just copy the IOS's result tlist?

I'm actively working on a prototype of partition pruning. It could be much=
=20
simpler if I just patched the core, but we have a working extension for 9.5=
=20
and 9.6, and we can't throw it away just yet. I wouldn't bother you if I=20
didn't encounter a broken query :)


--=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