Re: Split index and table statistics into different types of stats

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Daniel Gustafsson <daniel(at)yesql(dot)se>, "Gregory Stark (as CFM)" <stark(dot)cfm(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Split index and table statistics into different types of stats
Date: 2026-08-10 04:40:54
Message-ID: anlWVhngjRAuE2yF@bdtpg
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Thu, Aug 06, 2026 at 11:06:29AM +0900, Michael Paquier wrote:
> On Wed, Oct 02, 2024 at 01:48:11PM +0900, Michael Paquier wrote:
> > It could always be re-created later on, as required.
>
> And here is a blast from the past, following the recent effort I have
> been putting for the relfilenode statistics:
> https://www.postgresql.org/message-id/alCLr8ya-4ojew-x@paquier.xyz

Thanks!

> One of the conclusions I got out of this initial work is that the
> split of the index/table part makes more sense if tackled first, so
> here we are.
>
> As discussed, I am reposting refined versions of the patch set that
> splits the index and table stats, by introducing a new stats kind for
> indexes. There are two patches, split the facilities with different
> consequences:
> - 0001 refactors PgStat_StatTabEntry so as the data for indexes and
> tables in shmem is split. The advantage of this one is a reduction of
> the shared memory usage, as most of the fields of PgStat_StatTabEntry
> are not used for indexes. These are hidden behind a new stats kind.
> This is mostly bulk refactoring, with new SQL functions to retrieve
> the stats info. Note the PgStat_TableStatus bits in pgstat_index.c;
> these are tackled in 0002. This part is enough to reduce the shmem
> footprint of index stats.

I had a look at 0001 only, and I've a few comments.

=== 1

+pgstat_index_flush_cb(PgStat_EntryRef *entry_ref, bool nowait)
+{
.
.
.
+ /* The entry was successfully flushed, add the same to database stats */
+ dbentry = pgstat_prep_database_pending(dboid);
+ dbentry->blocks_fetched += lstats->counts.blocks_fetched;
+ dbentry->blocks_hit += lstats->counts.blocks_hit;

Shouldn't we add tuples_returned and tuples_fetched here too?

=== 2

pg_stat_reset_single_table_counters() public doc has been updated:

@@ -6022,7 +6040,7 @@ description | Waiting for a newly initialized WAL file to reach durable storage
<returnvalue>void</returnvalue>
</para>
<para>
- Resets statistics for a single table or index in the current database
+ Resets statistics for a single table in the current database

and also the pg_stat_get_numscans() and pg_stat_reset_single_table_counters()
descriptions in pg_proc.dat:

-{ oid => '1928', descr => 'statistics: number of scans done for table/index',
+{ oid => '1928', descr => 'statistics: number of scans done for table',
proname => 'pg_stat_get_numscans', provolatile => 's', proparallel => 'r',

- descr => 'statistics: reset collected statistics for a single table or index in the current database or shared across all databases in the cluster',
+ descr => 'statistics: reset collected statistics for a single table in the current database or shared across all databases in the cluster',

But it looks like that pg_stat_get_xact_numscans() descr has not been updated
in pg_proc.dat although it now returns 0 for indexes.

There is no public doc for pg_stat_get_numscans() and pg_stat_get_xact_numscans(),
so existing callers will get different behavior (that is not publicly documented).

Should we preserve the old behavior while keeping the new functions as explicit
alternatives? Or is it less of an issue given that those 2 don't have public
doc?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-08-10 05:01:58 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Michael Paquier 2026-08-10 04:38:31 Re: Redesign per-backend statistics