Re: Import Statistics in postgres_fdw before resorting to sampling.

>
> +
> I don't think that it's good to make StatisticsAreImportable() routine
> check if fetch_stats is enabled on foreign server/table options because
> if so, every fdw implementation would need this same block of code and
> also fdw implementations may forget or bypass these options which I
> don't think that it would be a desired behavior. What about move this
> check to analyze_rel()? Perhaps create a function that just check if the
> fetch_stats is enabled.
>

StatisticsAreImportable() is a virtual function whose goal is to determine
if this specific table supports stats exporting.

postgresStatisticsAreImportable() is the postgres_fdw implementation of
that virtual function.

Any other FDWs that want to implement stats import will need to invent
their own tests and configurations to determine if that is possible.

>
> If the above statement make sense, it seems to me that
> StatisticsAreImportable() may not be needed at all.
>

It wasn't there, initially.

>
> I think that we could make analyze_rel() check if fetch_stats is enable
> on the foreign server/table and then call ImportStatistics() which could
> return true or false.

That we can't do, because there's a chance that those FDWs already have a
setting named fetch_stats.

> If it returns true it means that the statistics
> was imported successfully, otherwise if it returns false we could
> fallback to table sampling as we already do today. ImportStatistics
> could return false if the foreign server don't have statistics for the
> requested table, even after running ANALYZE if remote_analyze is true.
>
> Is that make sense? Any thoughts?
>

That sounds very similar to the design that was presented in v1.