Re: Import Statistics in postgres_fdw before resorting to sampling.

>
>
> I too was thinking of network timeouts (and in such a case I thought
> that even if PQsendQuery was run successfully, the following
> PQgetResult would have to block for a long time). And yes, that
> situation can occur for normal queries, but in such a query, the extra
> functions call is done only when aborting the remote transaction, in a
> way libpq functions don't have to wait for a network timeout.
>

I've copied the ERROR-behavior that was already done
in postgresGetAnalyzeInfoForForeignTable(), which I assume will be to your
liking.

Structural error checks (how many columns does the result set have, etc)
are now elog errors, bad PQresultStatus-es are now errors as well.

The warnings when the query ran fine but no data was found are now NOTICE
level.

> I forgot to mention this, but when we have reltuples = 0 for v14 or
> later, the patch tries to import both relstats and attstats, but in
> that case I think it would be OK to do so only for the former for the
> consistency with the normal processing. What do you think about that?
>

I've update the logic that we don't try to fetch attrstats if the reltuples
is 0 or -1, and though the comments still mention the difference in server
version, the code behaves the same in new versions and old. My thinking is
that either value means "you are not going to find attstats" and our
reaction is the same either way.

I've also moved the column matching - finding which rows of the attstats
result set match to which columns in the local table - up into the fetch
portion, something you had mentioned wanting to see as well. This resulted
in some significant refactoring, but overall I think you will find the
changes for the better.