Possible regression regarding estimating relation width in FDWs

Hello,

While working on adapting the Multicorn FDW for 9.6, I noticed that there is a
regression with regards to estimating the remote relation width.

This behavior can be exposed using the postgres_fdw, using
"use_remote_estimate".

Test case:

CREATE EXTENSION postgres_fdw;
CREATE SERVER localhost FOREIGN DATA WRAPPER postgres_fdw;
CREATE USER MAPPING FOR CURRENT_USER SERVER localhost;
CREATE TABLE local_table (c1 text);
INSERT INTO local_table (c1) (SELECT repeat('test', 10000));
ANALYZE local_table;
CREATE FOREIGN TABLE foreign_table (c1 text) SERVER localhost OPTIONS
(table_name 'local_table', use_remote_estimate 'true');
EXPLAIN SELECT * FROM foreign_table;

Output, on current HEAD:

QUERY PLAN
----------------------------------------------------------------------
Foreign Scan on foreign_table (cost=100.00..101.03 rows=1 width=32)

On 9.5:
QUERY PLAN
-----------------------------------------------------------------------
Foreign Scan on foreign_table (cost=100.00..101.03 rows=1 width=472)

While the FDW correctly sets the pathtarget width, it is then overriden at a
later point. I'm not sure what happens exactly, but it seems that the relation
path target is ignored completely, in planner.c:1695:

/*
* Convert the query's result tlist into PathTarget format.
*
* Note: it's desirable to not do this till after query_planner(),
* because the target width estimates can use per-Var width numbers
* that were obtained within query_planner().
*/
final_target = create_pathtarget(root, tlist);

It says explicitly that it will be computed using per-Var width numbers.

I think the current_rel->cheapest_total_path->pathtarget should be taken into
account, at least in the FDW case.

I'm not sure if the ability to estimate the whole relation width should be
deprecated in favor of per-var width, or if it still should be supported
(after all, the GetForeignRelSize callback is called AFTER having set a value
computed from the individual attr_widths, in set_foreign_size). But in any
case, at least postgres_fdw should be updated to support that.

Sorry if that was not clear, I'm at PGCon at the moment so if anyone want to
discuss that in person I'm available.

--
Ronan Dunklau
http://dalibo.com - http://dalibo.org