Re: Vacuum statistics - Mailing list pgsql-hackers

From Andrei Zubkov
Subject Re: Vacuum statistics
Date
Msg-id e1f5b560691a4fe693625d529e19e13959210568.camel@moonset.ru
Whole thread Raw
In response to Vacuum statistics  (Alena Rybakina <lena.ribackina@yandex.ru>)
Responses Re: Vacuum statistics
List pgsql-hackers
Hi, Ilia!

> Do you consider not to create new table in pg_catalog but to save
> statistics in existing table? I mean pg_class or
> pg_stat_progress_analyze, pg_stat_progress_vacuum?
>
Thank you for your interest on our patch!

*_progress views is not our case. They hold online statistics while
vacuum is in progress. Once work is done on a table the entry is gone
from those views. Idea of this patch is the opposite - it doesn't
provide online statistics but it accumulates statistics about rosources
consumed by all vacuum passes over all relations. It's much closer to
the pg_stat_all_tables than pg_stat_progress_vacuum.

It seems pg_class is not the right place because it is not a statistic
view - it holds the current relation state and haven't anything about
the relation workload.

Maybe the pg_stat_all_tables is the right place but I have several
thoughts about why it is not:
- Some statistics provided by this patch is really vacuum specific. I
don't think we want them in the relation statistics view.
- Postgres is extreamly extensible. I'm sure someday there will be
table AMs that does not need the vacuum at all.

Right now vacuum specific workload views seems optimal choice to me.

Regards,

--
Andrei Zubkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: is_superuser versus set_config_option's parallelism check
Next
From: Alena Rybakina
Date:
Subject: Re: Asynchronous MergeAppend