statistics and check whether the relation or the
database are relevant now or not and if not, then
delete the vacuum statistics information for it. This may be
resource-intensive. The second way is to add hooks for deleting the
database and relationships (functions dropdb, index_drop,
heap_drop_wi
irst way is to add a background process that will go through the
> table with saved statistics and check whether the relation or the
> database are relevant now or not and if not, then
> delete the vacuum statistics information for it. This may be
> resource-intensive. The second way is t
a problem here with tracking deleted objects for which
> statistics are no longer needed. There are two solutions to this and I
> don't like both of them, to be honest.
> The first way is to add a background process that will go through the
> table with saved statistics and check whet
go through the
table with saved statistics and check whether the relation or the
database are relevant now or not and if not, then
delete the vacuum statistics information for it. This may be
resource-intensive. The second way is to add hooks for deleting the
database and relationships (f
On Fri, May 9, 2025 at 5:34 PM Alena Rybakina wrote:
>
> I did a rebase and finished the part with storing statistics separately from
> the relation statistics - now it is possible to disable the collection of
> statistics for relationsh using gucs and
> this allows us to solve the problem with
that are not in
pg_class? After all, we have views that show vacuum statistics for all
relations for objects stored in pg_class.
+CREATE VIEW pg_stat_vacuum_tables AS
...
FROM pg_class rel
+ JOIN pg_namespace ns ON ns.oid = rel.relnamespace,
+ LATERAL*pg_stat_get_vacuum_tables(rel.oid)* stats
On 10/28/24 14:40, Alexander Korotkov wrote:
On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
If I missed something or misunderstood, can you explain in more detail?
Actually, I mean why do we need a possibility to return statistics for
all tables/indexes in one function call? User anyway is su
;ll explain why.
I'm working on this issue [0] and try have already created new
statistics in Statistics Collector to store database and relation vacuum
statistics: PGSTAT_KIND_VACUUM_DB and PGSTAT_KIND_VACUUM_RELATION.
Vacuum statistics are saved there instead of relation's and databas
ch does affect more than just COMMIT).
> I will add it and fix the tests but later and I'll explain why.
>
> I'm working on this issue [0] and try have already created new statistics
> in Statistics Collector to store database and relation vacuum statistics:
> PGSTAT_KIND
ry have already created new
statistics in Statistics Collector to store database and relation
vacuum statistics: PGSTAT_KIND_VACUUM_DB and PGSTAT_KIND_VACUUM_RELATION.
Vacuum statistics are saved there instead of relation's and database's
statistic structure, but for some reas
On 17.03.2025 09:42, vignesh C wrote:
On Thu, 27 Feb 2025 at 23:30, Alena Rybakina wrote:
Hi!
On 17.02.2025 17:46, Alena Rybakina wrote:
On 04.02.2025 18:22, Alena Rybakina wrote:
Hi! Thank you for your review!
On 02.02.2025 23:43, Alexander Korotkov wrote:
On Mon, Jan 13, 2025 at 3:26 PM
On Thu, 27 Feb 2025 at 23:30, Alena Rybakina wrote:
>
> Hi!
> On 17.02.2025 17:46, Alena Rybakina wrote:
> > On 04.02.2025 18:22, Alena Rybakina wrote:
> >> Hi! Thank you for your review!
> >>
> >> On 02.02.2025 23:43, Alexander Korotkov wrote:
> >>> On Mon, Jan 13, 2025 at 3:26 PM Alena Rybakina
it, it
> >>>> should help.
> >>> The patch doesn't apply cleanly. Please rebase.
> >> I rebased them.
> > The patch needed a rebase again. There is nothing new since version
> > 18, only a rebase.
>
> The patch needed a new rebase.
>
>
Hi,
On Wed, Mar 12, 2025 at 05:15:53PM -0500, Jim Nasby wrote:
> The usecase I can see here is that we don't want autovac creating so much
> WAL traffic that it starts forcing other backends to have to write WAL out.
> But tracking how many times autovac writes WAL buffers won't help with that
Ri
On Wed, Mar 12, 2025 at 2:41 PM Alena Rybakina
wrote:
> Hi!
>
> On 10.03.2025 12:13, Ilia Evdokimov wrote:
> > Hi,
> >
> > After commit eaf5027 we should add information about wal_buffers_full.
> >
> > Any thoughts?
> >
> > --
> > Best regards,
> > Ilia Evdokimov,
> > Tantor Labs LLC.
> >
> I thi
Hi!
On 10.03.2025 12:13, Ilia Evdokimov wrote:
Hi,
After commit eaf5027 we should add information about wal_buffers_full.
Any thoughts?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
I think I can add it. To be honest, I haven't gotten to know this
statistic yet, haven't had time to get
ebase again. There is nothing new since version
18, only a rebase.
The patch needed a new rebase.
Sorry, but due to feeling unwell I picked up a patch from another thread
and squashed the patch for vacuum statistics for indexes and heaps in
the previous version. Now I fixed everything together wit
Hi,
After commit eaf5027 we should add information about wal_buffers_full.
Any thoughts?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
ase of GUC.
But could we move vacuum statistics to separate hash tables? When GUC
is disabled, new hash tables could be just empty.
Links
1.https://www.postgresql.org/message-id/CAD21AoD66b3u28n%3D73kudgMp5wiGiyYUN9LuC9z2ka6YTru5Gw%40mail.gmail.com
I understand what you're talking about. I&#
_vacuum_statistics,
> > which should address the increased size of statistics. However, I
> > don't see how it could affect the size of PgStat_StatTabEntry struct.
> > It seems that when pgstat_track_vacuum_statistics == 0, extended
> > vacuum statistics is not coll
disables
all collection of vacuum statistics. This patch can be seen here for
the 17th version of the patch [0], I have not yet started adding it,
since we did not come to an agreement.
I added this version as
"v19-0003.2-extended-vacuum-statistics.patch.no-cbot"
--
Regards,
Alen
se.
I see you introduced new GUC variable pgstat_track_vacuum_statistics,
which should address the increased size of statistics. However, I
don't see how it could affect the size of PgStat_StatTabEntry struct.
It seems that when pgstat_track_vacuum_statistics == 0, extended
vacuum statistics is no
On 10.01.2025 17:51, Alena Rybakina wrote:
Hi! I thought about this problem again and I think I have a solution.
On 02.12.2024 23:12, Alena Rybakina wrote:
* I've read the previous discussion on how important to keep all these
fields regarding vacuum statistics including points by Andre
Hi Sami,
Thank you for your attention to our patch and for your own work.
On Sun, 2025-01-05 at 20:00 -0600, Sami Imseih wrote:
>
> You make valid points. I now think because track_vacuum_statistics is
> optional, we should track total_time in 2 places. First place in the
> new
> view being prop
at if we remove
the total time from
the heap statistics and add it to pg_stat_tables and only leave the vacuum
statistics total time of
vacuum operation of indexes and databases?
It seems strange to me that they will have to be viewed from different views.
I think it is necessary to look at the t
Hi! I thought about this problem again and I think I have a solution.
On 02.12.2024 23:12, Alena Rybakina wrote:
* I've read the previous discussion on how important to keep all these
fields regarding vacuum statistics including points by Andrei and Jim.
It still worrying me that stati
_cleanup skipped, truncate phase
> skipped and toast vacuuming skipped ( the latter will only be relevant
> for the main relation ).
>
> I can add, but concerns have already been expressed about the large amount of
> vacuum statistics and, as a consequence, this leads
> to the all
the large
amount of vacuum statistics and, as a consequence, this leads to the
allocation of additional memory (3 times).
Of course, now we are saved by the guc I added for statistics... I
understand that this information can better show the efficiency of the
vacuum, but how does it help in
> I guess one question is how realistic it is to try and put everything about
> (auto)vacuum in a single view.
> Given the complexity, the answer to that might just be “no”. In that case
> leaving existing fields in pg_stat_all_tables
> is a lot more reasonable.
Agree. I also think the total_tim
On Jan 2, 2025, at 4:33 PM, Sami Imseih wrote:
>
>> While backwards compatibility is important, there’s definitely precedent for
>> changing
>> what shows up in the catalog. IMHO it’s better to bite the bullet and move
>> those fields
>> instead of having vacuum stats spread across two differen
>
> While backwards compatibility is important, there’s definitely precedent
> for changing what shows up in the catalog. IMHO it’s better to bite the
> bullet and move those fields instead of having vacuum stats spread across
> two different views.
>
-1. That's a huge change, and pg_stat_all_tabl
> While backwards compatibility is important, there’s definitely precedent for
> changing
> what shows up in the catalog. IMHO it’s better to bite the bullet and move
> those fields
> instead of having vacuum stats spread across two different views.
Correct, the most recent one that I could thin
> On Jan 2, 2025, at 2:12 PM, Sami Imseih wrote:
>
> Alternatively, we can remove the vacuum related stats from pg_stat_all_tables,
> but that will break monitoring tools and will leave us with the (auto)analyze
> metrics alone in pg_stat_all_tables. This sounds very ugly.
While backwards compa
Hi,
Thanks for the work you have done here. Exposing cumulative
metrics at this level of detail for vacuum is surely useful to find
vacuum bottlenecks and to determine the effectiveness of
vacuum tuning.
I am yet to look very closely, but I think some additional columns that
will be useful is the
Hi!
On 02.12.2024 17:46, Ilia Evdokimov wrote:
In my opinion, the patches are semantically correct. However, not all
dead code has been removed - I'm referring to
pgstat_update_snapshot(). Also, the tests need to be fixed.
I fixed it [0]. Thank you!
[0]
https://www.postgresql.org/message-
On 02.12.2024 17:46, Ilia Evdokimov wrote:
In my opinion, the patches are semantically correct. However, not all
dead code has been removed - I'm referring to
pgstat_update_snapshot(). Also, the tests need to be fixed.
Thank you, I'll fix it
--
Regards,
Alena Rybakina
Postgres Professional
Hi! Thank you for your review!
On 30.11.2024 07:48, Kirill Reshke wrote:
Hello!
After a brief glance, I think this patch set is good.
But there isn't any more time in the current CF to commit this :(.
So I moved to the next CF.
I agree with you. Thank you!)
I also like the 0001 commit message.
. Some points from me.
* I've read the previous discussion on how important to keep all these
fields regarding vacuum statistics including points by Andrei and Jim.
It still worrying me that statistics volume is going to burst in about
3 times, but I don't have a particular proposal on h
In my opinion, the patches are semantically correct. However, not all
dead code has been removed - I'm referring to pgstat_update_snapshot().
Also, the tests need to be fixed.
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
* I've read the previous discussion on how important to keep all these
fields regarding vacuum statistics including points by Andrei and Jim.
It still worrying me that statistics volume is going to burst in about
3 times, but I don't have a particular proposal on how to make more
granular a
On Wed, 13 Nov 2024 at 21:21, Alena Rybakina wrote:
>
> Hi! Thank you for your contribution to this thread!
>
> On 13.11.2024 03:24, Jim Nasby wrote:
>
> On Nov 10, 2024, at 2:09 PM, Alena Rybakina wrote:
>
>
> On 08.11.2024 22:34, Jim Nasby wrote:
>
>
> On Nov 2, 2024, at 7:22 AM, Alena Rybakina
On Nov 10, 2024, at 2:09 PM, Alena Rybakina wrote:
On 08.11.2024 22:34, Jim Nasby wrote:
On Nov 2, 2024, at 7:22 AM, Alena Rybakina
wrote:
On 08.11.2024 22:23, Alena Rybakina wrote:
Hi! Thank you for review!
On 07.11.2024 17:49, Ilia Evdokimov wrote:
Thank you for fixing it.
1) I have found some typos in the test output files (out-files) when
running 'make check' and 'make check-world'. These typos might cause
minor discrepan
> On Nov 2, 2024, at 7:22 AM, Alena Rybakina wrote:
>
>>> The second is the interrupts field. It is needed for monitoring to know
>>> do we have them or not, so tracking them on the database level will do
>>> the trick. Interrupt is quite rare event, so once the monitoring system
>>> will catch
Hi! Thank you for review!
On 07.11.2024 17:49, Ilia Evdokimov wrote:
Thank you for fixing it.
1) I have found some typos in the test output files (out-files) when
running 'make check' and 'make check-world'. These typos might cause
minor discrepancies in test results. You may already be awar
On 22.10.2024 22:30, Alena Rybakina wrote:
Hi!
On 16.10.2024 14:01, Alena Rybakina wrote:
Thank you for rebasing.
I have noticed that when I create a table or an index on this table,
there is no information about the table or index in
pg_stat_vacuum_tables and pg_stat_vacuum_indexes until
Hi!
On 29.10.2024 14:02, Alena Rybakina wrote:
On 28.10.2024 16:40, Alexander Korotkov wrote:
On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
wrote:
I didn't understand correctly - did you mean that we don't need SRF if
we need to display statistics for a specific object?
Otherwise, we need
nce the monitoring system
> will catch one the DBA can go to the server log for the details.
Just to confirm… by “interrupt” you mean vacuum encountered an error?
> It seems there is another way. If the vacuum stats doesn't seems to be
> mandatory in all systems, maybe we should add so
esn't seems to be
mandatory in all systems, maybe we should add some hooks to the vacuum
so that vacuum statistics tracking can be done in an extension. I don't
think it is a good idea, because vacuum stats seems to me as mandatory
as the vacuum process itself.
> Is there a reason some
On 28.10.2024 16:40, Alexander Korotkov wrote:
On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
wrote:
I didn't understand correctly - did you mean that we don't need SRF if
we need to display statistics for a specific object?
Otherwise, we need this when we display information on all database
.
>
> I agree with this point. Additionally, in order to benefit from
> gatherting vacuum statistics only for some relations in terms of
> space, we need to handle variable-size stat entries. That would
> greatly increase the complexity.
Could vacuum stats be treated as a se
On Sun, Sep 29, 2024 at 12:22 AM Alena Rybakina
wrote:
> Hi! Thank you for your interesting for this patch!
>
> I took a very brief look at this and was wondering if it was worth
> having a way to make the per-table vacuum statistics opt-in (like a
> table storage parameter) in or
On Sun, Aug 25, 2024 at 6:59 PM Alena Rybakina
wrote:
> I didn't understand correctly - did you mean that we don't need SRF if
> we need to display statistics for a specific object?
>
> Otherwise, we need this when we display information on all database
> objects (tables or indexes):
>
> while ((e
Hi Ilia,
On Wed, 2024-10-16 at 13:31 +0300, Ilia Evdokimov wrote:
> BTW, I recommend renaming the view pg_stat_vacuum_database to
> pg_stat_vacuum_databaseS for consistency with pg_stat_vacuum_tables
> and pg_stat_vacuum_indexes
Such renaming doesn't seems correct to me because
pg_stat_vacuum_da
Hi!
On 16.10.2024 13:31, Ilia Evdokimov wrote:
On 08.10.2024 19:18, Alena Rybakina wrote:
Made a rebase on a fresh master branch.
--
Regards,
Alena Rybakina
Postgres Professional
Thank you for rebasing.
I have noticed that when I create a table or an index on this table,
there is no infor
On 08.10.2024 19:18, Alena Rybakina wrote:
Made a rebase on a fresh master branch.
--
Regards,
Alena Rybakina
Postgres Professional
Thank you for rebasing.
I have noticed that when I create a table or an index on this table,
there is no information about the table or index in
pg_stat_vacuum
Hi! Thank you for your interesting for this patch!
I took a very brief look at this and was wondering if it was worth
having a way to make the per-table vacuum statistics opt-in (like a
table storage parameter) in order to decrease the shared memory
footprint of storing the stats.
I'm not
> > (minor-vacuum.no-cbot).
> >
> > Thank you for updating the patches. I've reviewed the 0001 patch and
> > have two comments.
>
> I took a very brief look at this and was wondering if it was worth
> having a way to make the per-table vacuum statistics
n't be accounted by the pg_stat_statements. After all,
pg_stat_statements won't hold the statements statistics forever. Under
pressure of new statements the statement eviction can happen and
statistics will be lost.
All of the above is addressed by relation-level vacuum statistics held
in the Cumu
1:23 AM Alena Rybakina
> > wrote:
> >
> > Hi, all!
> >
> > I have attached the new version of the code and the diff files
> > (minor-vacuum.no-cbot).
>
> Thank you for updating the patches. I've reviewed the 0001 patch and
> have two comments.
I took
iff files
> (minor-vacuum.no-cbot).
Thank you for updating the patches. I've reviewed the 0001 patch and
have two comments.
I think we can split the 0001 patch into two parts: adding
pg_stat_vacuum_tables system views that shows the vacuum statistics
that we are currently collecting suc
On Thu, Sep 5, 2024 at 1:23 AM Alena Rybakina wrote:
>
> Hi, all!
>
> I have attached the new version of the code and the diff files
> (minor-vacuum.no-cbot).
>
hi.
still have white space issue when using "git apply",
you may need to use "git diff --check" to find out where.
/* --
dif
torestate
*tupstore,
values[i++] = Float8GetDatum(tabentry->vacuum_ext.total_time);
values[i++] = Int32GetDatum(tabentry->vacuum_ext.interrupts);
- Assert(i == ncolumns);
-
- tuplestore_putvalues(tupstore, tupdesc, values, nulls);
+ Assert(i == rsinfo->set
On 22.08.2024 07:29, Kirill Reshke wrote:
On Thu, 22 Aug 2024 at 07:48, jian he wrote:
On Wed, Aug 21, 2024 at 6:37 AM Alena Rybakina
wrote:
We check it there: "tabentry->vacuum_ext.type != type". Or were you talking
about something else?
On 19.08.2024 12:32, jian he wrote:
in pg_stats_va
On 22.08.2024 05:47, jian he wrote:
On Wed, Aug 21, 2024 at 6:37 AM Alena Rybakina
wrote:
We check it there: "tabentry->vacuum_ext.type != type". Or were you talking
about something else?
On 19.08.2024 12:32, jian he wrote:
in pg_stats_vacuum
if (type == PGSTAT_EXTVAC_INDEX || type ==
DatabaseId = storedMyDatabaseId;
+ }
+ PG_END_TRY();
I think this is generally wrong to change MyDatabaseId, especially if you
have to wrap it with PG_TRY()/PG_CATCH(). I think, instead we need proper
API changes, i.e. make pgstat_fetch_stat_tabentry() and others take dboid
as an a
On Thu, 22 Aug 2024 at 07:48, jian he wrote:
>
> On Wed, Aug 21, 2024 at 6:37 AM Alena Rybakina
> wrote:
> >
> > We check it there: "tabentry->vacuum_ext.type != type". Or were you talking
> > about something else?
> >
> > On 19.08.2024 12:32, jian he wrote:
> >
> > in pg_stats_vacuum
> > if
On Wed, Aug 21, 2024 at 6:37 AM Alena Rybakina
wrote:
>
> We check it there: "tabentry->vacuum_ext.type != type". Or were you talking
> about something else?
>
> On 19.08.2024 12:32, jian he wrote:
>
> in pg_stats_vacuum
> if (type == PGSTAT_EXTVAC_INDEX || type == PGSTAT_EXTVAC_HEAP)
> {
I think you've counted the above system tables from the database, but
I'll double-check it. Thank you for your review!
On 19.08.2024 19:28, Ilia Evdokimov wrote:
Are you certain that all tables are included in
`pg_stat_vacuum_tables`? I'm asking because of the following:
SELECT count(*) FROM
We check it there: "tabentry->vacuum_ext.type != type". Or were you
talking about something else?
On 19.08.2024 12:32, jian he wrote:
in pg_stats_vacuum
if (type == PGSTAT_EXTVAC_INDEX || type == PGSTAT_EXTVAC_HEAP)
{
Oidrelid = PG_GETARG_OID(1);
to display table statistics only
for the current database, that is, this part will be removed in the
future. In my opinion, it would be more correct.
the following code one function has 2 return statements?
/*
* Get the vacuum statistics for the heap tables.
*/
Datum
pg
Are you certain that all tables are included in `pg_stat_vacuum_tables`?
I'm asking because of the following:
SELECT count(*) FROM pg_stat_all_tables ;
count
---
108
(1 row)
SELECT count(*) FROM pg_stat_vacuum_tables ;
count
---
20
(1 row)
--
Regards,
Ilia Evdokimov,
Tantor L
in pg_stats_vacuum
if (type == PGSTAT_EXTVAC_INDEX || type == PGSTAT_EXTVAC_HEAP)
{
Oidrelid = PG_GETARG_OID(1);
/* Load table statistics for specified database. */
if (OidIsValid(relid))
{
tabentry = fetch_dbstat_tabentry(dbi
TVACSTAT_COLUMNS Max(EXTVACHEAPSTAT_COLUMNS, EXTVACIDXSTAT_COLUMNS)
static Oid CurrentDatabaseId = InvalidOid;
>>>>
we already defined MyDatabaseId in src/include/miscadmin.h,
Why do we need "static Oid CurrentDatabaseId = InvalidOid;"?
also src/backend/utils/adt/pgstatfuncs
On 15.8.24 11:49, Alena Rybakina wrote:
I have some suggestions:
1. pgstatfuncs.c in functions tuplestore_put_for_database() and
tuplestore_put_for_relation you can remove 'nulls' array if
you're sure that columns cannot be NULL.
We need to use this for tuplestore_putvalues function.
And I have one suggestion for pg_stat_vacuum_database: I suppose we
should add database's name column after 'dboid' column because it is
difficult to read statistics without database's name. We could call it
'datname' just like in 'pg_stat_database' view.
Regards,
Ilia Evdokimov,
Tantor Labs
On 10.8.24 22:37, Andrei Zubkov wrote:
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.
them will contain code for collecting vacuum
> statistics on tables, the second on indexes and the last on databases.
>
> I have divided the patch into three: the first patch contains code for the
> functionality of collecting and storage for tables, the second one for
> indexes and th
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 whil
Hello, everyone!
Thank you for your interesting patch with extended information
statistics about autovacuum.
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?
P.S. If I sent
Hello!
On Thu, 27/06/2024 at 10:39 +0900, Masahiko Sawada:
> On Fri, May 31, 2024 at 4:19 AM Andrei Zubkov
> wrote:
> > As the vacuum process is a backend it has a workload
> > instrumentation.
> > We have all the basic counters available such as a number of blocks
> > read, hit and written, time
On Fri, May 31, 2024 at 4:19 AM Andrei Zubkov wrote:
>
> Hi,
>
> Th, 30/05/2024 at 10:33 -0700, Alena Rybakina wrote:
> > I suggest gathering information about vacuum resource consumption for
> > processing indexes and tables and storing it in the table and index
> > relationships (for example, Pg
the system views that are used in the
machinery of vacuum statistics.
---
doc/src/sgml/system-views.sgml | 747 +
1 file changed, 747 insertions(+)
diff --git a/doc/src/sgml/system-views.sgml b/doc/src/sgml/system-views.sgml
index 67a42a1c4d4..dfef8ed44b8 100644
Hi!
On 11.06.2024 16:09, Alena Rybakina wrote:
On 08.06.2024 09:30, Alena Rybakina wrote:
Iam currentlyworkingondividingthispatchintothreepartstosimplifythe
reviewprocess:oneofthemwillcontaincodeforcollectingvacuumstatisticsontables,the
secondonindexesandthe lastondatabases.
I have divided
On Thu, May 30, 2024 at 11:57 PM Alena Rybakina
wrote:
>
> On 30.05.2024 10:33, Alena Rybakina wrote:
> >
> > I suggest gathering information about vacuum resource consumption for
> > processing indexes and tables and storing it in the table and index
> > relationships (for example, PgStat_StatTab
Hi,
Th, 30/05/2024 at 10:33 -0700, Alena Rybakina wrote:
> I suggest gathering information about vacuum resource consumption for
> processing indexes and tables and storing it in the table and index
> relationships (for example, PgStat_StatTabEntry structure like it has
> realized for usual stati
PATCH] Machinery for grabbing an extended vacuum statistics on
relations. Remember, statistic on heap and index relations a bit different.
Value of total_blks_hit, total_blks_read, total_blks_dirtied are number of
hitted, missed and dirtied pages in shared buffers during a vacuum operation
respect
Hello, everyone!
I think we don't have enough information to analyze vacuum functionality.
Needless to say that the vacuum is the most important process for a
database system. It prevents problems like table and index bloating and
emergency freezing if we have a wraparound problem. Furthermore
88 matches
Mail list logo
