Re: pg_stat_statements oddity with track = all
От | Julien Rouhaud |
---|---|
Тема | Re: pg_stat_statements oddity with track = all |
Дата | |
Msg-id | 20201202082402.GB51769@nol обсуждение исходный текст |
Ответ на | Re: pg_stat_statements oddity with track = all (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: pg_stat_statements oddity with track = all
|
Список | pgsql-hackers |
On Wed, Dec 02, 2020 at 03:52:37PM +0900, Fujii Masao wrote: > > On 2020/12/02 15:32, Julien Rouhaud wrote: > > On Tue, Dec 01, 2020 at 10:08:06PM -0800, Nikolay Samokhvalov wrote: > > > On Tue, Dec 1, 2020 at 8:05 PM Julien Rouhaud <rjuju123@gmail.com> wrote: > > > > > > > Someone raised an interested point recently on pg_stat_kcache extension for > > > > handling nested statements, which also applies to pg_stat_statements. > > > > > > > ... > > > > > > > The only idea I have for that is to add a new field to entry key, for > > > > instance > > > > is_toplevel. > > [...] > > Just idea; instead of boolean is_toplevel flag, what about > counting the number of times when the statement is executed > in toplevel, and also in nested level? Ah, indeed that would avoid extraneous entries. FTR we would also need that for the planning part. The cons I can see is that it'll make the counters harder to process (unless we provide a specific view for the top-level statements only for instance), and that it assumes that doing a simple division is representative enough for the top level/nested repartition. This might be quite off for in some cases, e.g. big stored procedures due to lack of autovacuum, but that can't be worse than what we currently have.
В списке pgsql-hackers по дате отправления: