From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dmitry Ivanov <d.ivanov@postgrespro.ru>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Possible problem in Custom Scan API
Date: Wed, 12 Apr 2017 12:03:46 -0400
Message-ID: <8130.1492013026@sss.pgh.pa.us> (raw)
In-Reply-To: <0e0388a6-aa53-42a6-8be9-0d46ccbc788e@postgrespro.ru>
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>
<0e0388a6-aa53-42a6-8be9-0d46ccbc788e@postgrespro.ru>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Dmitry Ivanov <d.ivanov@postgrespro.ru> writes:
>> 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
> and every Var that's been requested. If I'm correct, the only way to ensure
> that is to call build_path_tlist(), which is static (oops!). Perhaps I
> could make my own, but it uses replace_nestloop_params() (again, static),
> and the problem goes further and further.
True. We could expose build_path_tlist(), perhaps, but then you soon
reach the conclusion that PlanCustomPath should also be given access to
the tlist-related "flags" that are being passed around in createplan.c,
and that's a conclusion I don't want to reach. That whole business is
a bit of a hack that I hope to redesign someday, but if we embed it in
the custom-scan API it will get very hard to change.
I'm coming around to the idea that it'd be better to disable physical
tlists for custom scans. That optimization is built on the assumption
that providing all the columns is free (or at least, cheaper than doing
ExecProject), but it's easy to think of custom-scan applications where
that's not true. It's a disastrous choice for a custom-scan provider
that's trying to interface to a column store, for instance.
However, I'm hesitant to make such a change in the back branches; if
there's anyone using custom scans who's negatively affected, they'd be
rightfully unhappy. Are you satisfied if we change this in HEAD?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, d.ivanov@postgrespro.ru
Subject: Re: Possible problem in Custom Scan API
In-Reply-To: <8130.1492013026@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox