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 | CAA4eK1KbgCsKss5vM79uKqY1trg0XmCU9EnYRf2uWMfQcbPf6g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: New function pg_stat_statements_reset_query() to reset statisticsof a specific query (Haribabu Kommi <kommi.haribabu@gmail.com>) |
Список | pgsql-hackers |
On Fri, Nov 23, 2018 at 4:40 AM Haribabu Kommi <kommi.haribabu@gmail.com> wrote: > > > On Fri, Nov 23, 2018 at 1:54 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: >> >> On 19/11/2018 06:18, Haribabu Kommi wrote: >> > Amit suggested another option in another mail, so total viable >> > solutions that are discussed as of now are, >> > >> > 1. Single API with NULL input treat as invalid value >> > 2. Multiple API to deal with NULL input of other values >> > 3. Single API with NULL value to treat them as current user, current >> > database >> > and NULL queryid. >> > 4. Single API with -1 as invalid value, treat NULL as no matching. (Only >> > problem >> > with this approach is till now -1 is also a valid queryid, but setting >> > -1 as queryid >> > needs to be avoided. >> >> Can you show examples of what these would look like? > > > Following are some of the examples how the various options > work. > Do the examples provided by Haribabu helps in understanding the proposal? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: