Re: [PROPOSAL] VACUUM Progress Checker.

Hi,

At Thu, 10 Mar 2016 08:21:36 +0000, <pokurev(at)pm(dot)nttdata(dot)co(dot)jp> wrote in <8e09c2fe530d4008aa0019e38c1d5453(at)MP-MSGSS-MBX007(dot)msg(dot)nttdata(dot)co(dot)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