Re: Import Statistics in postgres_fdw before resorting to sampling.

On Wed Jan 7, 2026 at 4:17 PM -03, Corey Huinker wrote:
>>
>> +
>> 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.
>
Ok, now I understand. I thought that fetch_stats and remote_analyze was
a generally fdw option and not only specific to postgres_fdw. Now I
understand that is up to the fdw implementation decide how this should
be enabled or disabled. Thanks for making it clear now.

>> 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.
>
Yeah, I think that my suggestion don't make sense, I miss understood the
feature. Sorry about the noise, I'll continue reviewing the v8 patch.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com