I think that that would be the user's fault, as it's the user's responsibility to ensure that the existing stats for the remote table are up-to-date. From another perspective, not all users will be able to operate in such a way, so I'm thinking of disabling this feature by default.
I'd like it to remain on by default, and the handling of this edge case can be made configurable in the future, so I'm fine with it for now.
> I see that remote_analyze didn't make it as a part of this patch. Is that something you'd repackaged as a follow-on patch, or are you just done with it?
As just reviewing/polishing the 0001/0002 patches is a lot of work, I didn't have time to look at the remote_analyze patch. We are running out of time, so I'm afraid that I won't be able to have time for that.
Fair enough.
I modified the patch further:
* Modified postgresImportStatistics to create RemoteAttributeMapping if needed.
+1
* The query executed in fetch_relstats is almost the same as the one executed in postgresGetAnalyzeInfoForForeignTable. To avoid code duplication, I modified it to use the latter query.
+1. That always bothered me.
* Modified import_spi_query_ok to get the result of an import query by using SPI_getbinval, not SPI_getvalue, for efficiency.
