Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query
От | Amit Kapila |
---|---|
Тема | Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query |
Дата | |
Msg-id | CAA4eK1LicqWY55XxmahQXti4RjQ28iuASAk1X8+yKX0J051_VQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query (Sergei Kornilov <sk@zsrv.org>) |
Ответы |
Re: New function pg_stat_statements_reset_query() to resetstatistics of a specific query
|
Список | pgsql-hackers |
On Wed, Nov 28, 2018 at 4:45 PM Sergei Kornilov <sk@zsrv.org> wrote: > > Hello > > > My preference is for NULL to mean *all* so this is my favorite option, > > except that the first query should reset everything. > > I am +1 for this option. NULL treat as "any" and pg_stat_statements_reset(NULL,NULL,NULL) to reset everything > The problem with this idea is that if someone specifies a particular parameter using query and the query doesn't return any parameters, then it can lead to inadvertent behavior. For example, if user uses something like pg_stat_statements_reset(<valid_user_id>, <valid_db_id>, SELECT s.queryid FROM pg_stat_statements AS s WHERE s.query = 'SELECT $1 AS "ONE"'); now, if the query doesn't return any row, we will remove the stats for all queries that belong to (userid,dbid). It could be surprising for some users, that's why we came up with option-4 where we keep the default value of parameters as 0. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: