Re: Support reset of Shared objects statistics in "pg_stat_reset" function - Mailing list pgsql-hackers

From Mahendra Singh Thalor
Subject Re: Support reset of Shared objects statistics in "pg_stat_reset" function
Date
Msg-id CAKYtNAqbbUGGdcq6JDVNJggziri3H-G6Aw4n4z-TH==CXSZEmw@mail.gmail.com
Whole thread Raw
In response to Re: Support reset of Shared objects statistics in "pg_stat_reset" function  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Support reset of Shared objects statistics in "pg_stat_reset" function  (Sadhuprasad Patro <b.sadhu@gmail.com>)
List pgsql-hackers
On Wed, 11 Aug 2021 at 09:17, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Tue, Aug 10, 2021 at 10:49 PM Mahendra Singh Thalor
> <mahi6run@gmail.com> wrote:
>
> > I checked this and found that we already have one process "stats
> > collector" and in v02 patch, we are sending requests to collect stats
> > two times. I don't know how costly one call is but I feel that we can
> > avoid the 2nd call by keeping handling of the shared tables into
> > pgstat_recv_resetcounter.
> >
>
> I think let's not make the stat collector aware of what we want to
> achieve, so the stat collector will only reset for what we have asked
> for and let the caller or the signal sender decide what they want to
> do.
>
Thanks Dilip for your opinion.

If we want to use pgstat_recv_resetcounter with invalid database oid,
then we should update all the comments of pgstat_recv_resetcounter
function because we are calling this function with both valid and
invalid database oid.
If we are passing invalid database oid, it means we want to reset
stats for shared tables.

1)
    /*
     * Lookup the database in the hashtable.  Nothing to do if not
there.
     */
    dbentry = pgstat_get_db_entry(msg->m_databaseid, false);
We should update the above comment and if m_databaseid is invalid,
then we should always get dbentry.

Assert (msg->m_databaseid == 0 && dbentry ) and some more sanity checks.

2)
    /*
     * We simply throw away all the database's table entries by recreating a
     * new hash table for them.
     */
I think we should update this also.

3)
*  Reset the statistics for the specified database.
This should be updated.

-- 
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Fix around conn_duration in pgbench
Next
From: Amit Kapila
Date:
Subject: Re: [BUG]Update Toast data failure in logical replication