Re: pg_stat_statements oddity with track = all
| От | Julien Rouhaud |
|---|---|
| Тема | Re: pg_stat_statements oddity with track = all |
| Дата | |
| Msg-id | 20201203085359.GC8050@nol обсуждение исходный текст |
| Ответ на | Re: pg_stat_statements oddity with track = all (Sergei Kornilov <sk@zsrv.org>) |
| Ответы |
Re: pg_stat_statements oddity with track = all
|
| Список | pgsql-hackers |
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 chance ofcopypaste 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.
В списке pgsql-hackers по дате отправления: