Re: pg_stat_statements oddity with track = all

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: pg_stat_statements oddity with track = all
Дата
Msg-id 20201204081548.GA76762@nol
обсуждение исходный текст
Ответ на Re: pg_stat_statements oddity with track = all  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: pg_stat_statements oddity with track = all  (Sergei Kornilov <sk@zsrv.org>)
Список pgsql-hackers
On Thu, Dec 03, 2020 at 04:53:59PM +0800, Julien Rouhaud wrote:
> On Thu, Dec 03, 2020 at 11:40:22AM +0300, Sergei Kornilov wrote:
> > Hello
> > 
> > > To get an increase in the number of records that means that the same
> > > statement
> > > would appear at top level AND nested level. This seems a corner case with
> > > very low
> > > (neglectible) occurence rate.
> > 
> > +1
> > I think splitting fields into plans_toplevel / plans_nested will be less convenient. And more code with higher
chanceof copypaste errors
 
> 
> As I mentioned in a previous message, I really have no idea if that would be a
> corner case or not.  For instance with native partitioning, the odds to have
> many different query executed both at top level and as a nested statement may
> be quite higher.

The consensus seems to be adding a new boolean toplevel flag in the entry key,
so PFA a patch implementing that.  Note that the key now has padding, so
memset() calls are required.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "tsunakawa.takay@fujitsu.com"
Дата:
Сообщение: RE: In-placre persistance change of a relation
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit