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  (legrand legrand <legrand_legrand@hotmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: proposal: unescape_text function
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions