Re: Support reset of Shared objects statistics in "pg_stat_reset" function

Поиск
Список
Период
Сортировка
От Mahendra Singh Thalor
Тема Re: Support reset of Shared objects statistics in "pg_stat_reset" function
Дата
Msg-id CAKYtNAqbbUGGdcq6JDVNJggziri3H-G6Aw4n4z-TH==CXSZEmw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support reset of Shared objects statistics in "pg_stat_reset" function  (Dilip Kumar <dilipbalaut@gmail.com>)
Ответы Re: Support reset of Shared objects statistics in "pg_stat_reset" function  (Sadhuprasad Patro <b.sadhu@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Fix around conn_duration in pgbench
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [BUG]Update Toast data failure in logical replication