And pg_catalog.pg_statistics_gtt() is set returning functions? > yes
I afraid that it is not acceptable solution from performance point of view: > pg_statictic table is accessed by keys (<relid>,<attpos>,<inh>) > I don't think so it is problem. The any component, that needs to use fast access can use some special function that check index or check some memory buffers. If it can not be done using index scan, then it can cause significant > performance slow down. > where you need fast access when you use SQL access? Inside postgres optimizer is caches everywhere. And statistics cache should to know so have to check index and some memory buffers. The proposed view will not be used by optimizer, but it can be used by some higher layers. I think so there is a agreement so GTT metadata should not be stored in system catalogue. If are stored in some syscache or somewhere else is not important in this moment. But can be nice if for user the GTT metadata should not be black hole. I think so is better to change some current tables to views, than use some special function just specialized for GTT (these functions should to exists in both variants). When I think about it - this is important not just for functionality that we expect from GTT. It is important for consistency of Postgres catalog - how much different should be GTT than other types of tables in system catalogue from user's perspective.
