Re: Import Statistics in postgres_fdw before resorting to sampling.

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