+ 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.
