Re: Import Statistics in postgres_fdw before resorting to sampling.

>
> > I'm not sure we can actually do that. The functions that compute the
> statistics are all based off of row samples, not already computed
> statistics. I don't think we can synthesize a rowsample from the imported
> statistics, at least not accurately. If I'm misunderstanding what you're
> suggesting, please correct me.
>
> I am comparing the calculation of statistics to the calculation of
> aggregates. We have code to compute aggregates on a partitioned table
> from the partial aggregates computed from the individual partitions.
> (Even though I am mentioning the partitioned table, the technique can
> be used for an inheritance hierarchy.) Similarly if we could come up

with a representation of partial statistics, we could get partial
> statistics computed for the children (and the parent in
> non-partitioned inheritance). Use the partial statistics to compute
> the statistics for the parent without the need to synthesize row
> samples from the children. I haven't looked at all the kinds of
> statistics to see whether this is feasible.
>

We're limited to the existing data from pg_class and the security-barrier
view pg_stats. We also have pg_stats_ext and pg_stats_ext_exprs as well,
but those are for extended stats objects, which aren't useful to us in this
context.

I've been a part of some research into the feasibility of caching the row
samples fetched, allowing the planner to generate on-the-fly statistics for
OLAP queries. If we ever got that functionality, we'd need a means of
exposing those row samples externally, and even then we'd have to wait for
the remote postgresql server to have that feature. So for now we are
limited to what pg_class and pg_stats tell us.