> > 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. +1. Everything checks out over here.
