Re: [HACKERS] [PATCHES] log_statement output for protocol
От | Guillaume Smet |
---|---|
Тема | Re: [HACKERS] [PATCHES] log_statement output for protocol |
Дата | |
Msg-id | 1d4e0c10608260434h4940da5anf96c1e48b8e1d151@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCHES] log_statement output for protocol (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [HACKERS] [PATCHES] log_statement output for protocol
|
Список | pgsql-jdbc |
On 8/7/06, Bruce Momjian <bruce@momjian.us> wrote: > Updated patch attached. It prints the text bind parameters on a single > detail line. I still have not seen portal names generated by libpq. I'm currently testing CVS tip to generate sample log files. I noticed that Bruce only patched log_statement and not log_min_duration_statement which still has the old behaviour ie: [1-1] LOG: duration: 0.097 ms execute my_query: SELECT * FROM shop WHERE name = $1 The problem of not having the bind parameters still remains. A lot of people use log_min_duration_statement and it's usually recommended to use it instead of log_statement because log_statement generates far too much output. I tried to find a way to fix it but it's not so simple as when we bind the statement, we don't know if the query will be slower than log_min_duration_statement. My first idea is that we should add a DETAIL line with the parameter values to the execute log line when we are in the log_min_duration_statement case. AFAICS the values are in the portal but I don't know the overhead introduced by generating the detail line from the portal. Does anyone have a better idea on how we could fix it? Regards, -- Guillaume
В списке pgsql-jdbc по дате отправления: