Dmitry Ivanov <d.iva...@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
