Re: [PROPOSAL] VACUUM Progress Checker.

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: [PROPOSAL] VACUUM Progress Checker.
Дата
Msg-id 56E12B91.1020300@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: [PROPOSAL] VACUUM Progress Checker.  (<pokurev@pm.nttdata.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 Vinayak,

Thanks for the quick review!

On 2016/03/10 16:22, pokurev@pm.nttdata.co.jp wrote:
>> On 2016/03/10 14:29, Amit Langote wrote:
>> Updated patches attached.
> In 0002-

[ snip ]

> I think we need to use datid instead of datname.
> Robert added datid in pg_stat_get_progress_info() and we are using that function here.
> +values[1] = ObjectIdGetDatum(beentry->st_databaseid);

[ snip ]

> So I think it's better to report datid not datname.
> The definition of view is simply like:
> +CREATE VIEW pg_stat_progress_vacuum AS
> +    SELECT
> +            S.pid AS pid,
> +            S.datid AS datid,
> +            S.relid AS relid,
> +            CASE S.param1
> +                WHEN 1 THEN 'scanning heap'
> +                WHEN 2 THEN 'vacuuming indexes'
> +                WHEN 3 THEN 'vacuuming heap'
> +                WHEN 4 THEN 'cleanup'
> +                ELSE 'unknown phase'
> +            END AS processing_phase,
> +            S.param2 AS total_heap_blocks,
> +            S.param3 AS current_heap_block,
> +            S.param4 AS total_index_blocks,
> +            S.param5 AS index_blocks_done,
> +            S.param6 AS index_vacuum_count,
> +            CASE S.param2
> +                WHEN 0 THEN round(100.0, 2)
> +                ELSE round((S.param3 + 1) * 100.0 / S.param2, 2)
> +            END AS percent_done
> +    FROM pg_stat_get_progress_info('VACUUM') AS S;
>
> 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.

Thanks,
Amit

Вложения

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: POC: Cache data in GetSnapshotData()
Следующее
От: "Regina Obe"
Дата:
Сообщение: Re: Is there a way around function search_path killing SQL function inlining?