Re: log_duration
| От | Tom Lane |
|---|---|
| Тема | Re: log_duration |
| Дата | |
| Msg-id | 4984.1107711157@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: log_duration ("Simon Riggs" <simon@2ndquadrant.com>) |
| Ответы |
Re: log_duration
|
| Список | pgsql-admin |
"Simon Riggs" <simon@2ndquadrant.com> writes:
> Further update on this:
> We've isolated this issue to JDBC client access.
Ah-hah, now it makes sense. I believe the JDBC driver always uses
extended query protocol (parse/bind/execute messages). We know that
that code path is a bit shy of a load with respect to statement logging,
mainly because no one has worked out exactly what it ought to log and
when. When you consider the possibilities for re-use of parsed
statements and partial execution of portals, it's not clear what a
"statement" is, let alone what its "duration" is. Maybe the real
problem is that the GUC variables are defined in terms of a too
simplistic view of the world.
As a quick workaround until someone thinks of a better idea, it might be
sufficient to attach logging code to the execute phase, and ignore the
partial-execution issue.
regards, tom lane
В списке pgsql-admin по дате отправления: