Per side conversation in [1], this patch exposes pg_statistic.starelid in the pg_stats view (0001) and then changes pg_dump to use the starelid in the queries on pg_stats rather than the combination of schemaname+relname, which gets a bit clumsy in bulk array fetching, and also leads to bad query plans against pg_stats because the security barrier is also an optimization barrier, which means that queries often try to hash join, which causes the very large table pg_statistic to be sequentially scanned, and that's a bad time. Currently we get around this by adding a redundant qual to the query which gooses the plan towards an index, and that works fine for now, but there's no guarantee that it will continue to work in the future, so this change brings some plan safety as well.
0001 also exposes pg_statistic.attnum. This is no direct application of this in 0002, but people have often expressed surprise that pg_dump orders the pg_restore_attribute_stats() calls by attname rather than attnum, and if we wanted to change that now we could (albeit only on new versions).
