Re: [PROPOSAL] VACUUM Progress Checker.

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: [PROPOSAL] VACUUM Progress Checker.
Дата
Msg-id 20160310.201021.263932870.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [PROPOSAL] VACUUM Progress Checker.  (<pokurev@pm.nttdata.co.jp>)
Ответы Re: [PROPOSAL] VACUUM Progress Checker.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Is there a way around function search_path killing SQL function inlining?
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: psql completion for ids in multibyte string