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