Re: [PROPOSAL] VACUUM Progress Checker.

Hi,

At Thu, 10 Mar 2016 08:21:36 +0000, <pokurev@pm.nttdata.co.jp> wrote in
<8e09c2fe530d4008aa0019e38c1d5453@MP-MSGSS-MBX007.msg.nttdata.co.jp>
> > > So maybe we can add datname as separate column in
> > pg_stat_progress_vacuum, I think it's not required only datid is sufficient.
> > > Any comment?
> > 
> > Why do you think showing the name may be unacceptable?  Wouldn't that
> > be a little more user-friendly?  Though maybe, we can follow the
> > pg_stat_activity style and have both instead, as you suggest.  Attached
> > updated version does that.
> +1
> I think reporting both (datid and datname) is more user-friendly.
> Thank you.

I don't like showing both oid and name and only "user friendry"
doesn't seem to justify adding redundant columns in-a-sense.

So, I have looked into system_views.sql and picked up what
catalogs/views shows objects in such way, that is, showing both
object id and its name.

Show by name: pg_policies, pg_rules, pg_tablespg_matviews,             pg_indexes, pg_stats, pg_prepared_xacts,
pg_seclabels,     pg_stat(io)_*_tables/indexes.schemaname             pg_stat_*_functions.schemaname
 

Show by oid : pg_locks, pg_user_mappings.umid

Both        : pg_stat(io)_*_tables/indexes.relid/relname, indexrelid/indexname;
pg_stat_activity.datid/datname,usesysid/usename             pg_stat_activity.datid/datname, usesysid/usename
pg_replication_slots.datoid/database             pg_stat_database(_conflicts).datid/datname
pg_stat_*_functions.funcid/funcname            pg_user_mappings.srvid/srvname,umuser/usename
 

It's surprising to see this result for me. The nature of this
view is near to pg_stat* views so it is proper to show *both of
database and relation* in both of oid and name.

Thoughts?

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center