Re: statement logging / extended query protocol issues
От | Simon Riggs |
---|---|
Тема | Re: statement logging / extended query protocol issues |
Дата | |
Msg-id | 1126112904.3956.400.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: statement logging / extended query protocol issues (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: statement logging / extended query protocol issues
(Oliver Jowett <oliver@opencloud.com>)
|
Список | pgsql-hackers |
On Tue, 2005-09-06 at 07:47 +0000, Oliver Jowett wrote: > Simon Riggs wrote: > > > Looking more closely, I don't think either is correct. Both can be reset > > according to rewind operations - see DoPortalRewind(). > > > > We'd need to add another bool onto the Portal status data structure. > > AFAIK this is only an issue with SCROLLABLE cursors, which v3 portals > aren't. OK, that may be so, but the internals don't know that. If I use atEnd or atStart then messages would differ from v3 to v2. It would then be easy to confuse v2 cursor actions with multiple re-executions in v3. I want to be able to look at the log and work out what happened, not to start asking questions like "do you use v2, v3 or a mix of both?". > > If queries are short and yet there is much fetching, we may see a > > program whose main delay is because of program-to-server delay because > > of fetching. So, I'd like to see that in the log, but I agree with your > > earlier comments that it should be a shorter log line. > > I'm coming from the point of view of a user who wants to "just turn on > query logging". The mechanics of the portals aren't of interest to them. > Currently, "log_statement = all" produces markedly different output > depending on whether the extended query protocol is used or not, which > is very much an implementation detail.. ...and I hope it would, since the impact on the server differs. I want the log to reflect what has happened on the server. > How about "log_statement = verbose" or something similar to enable > logging of all the details, and have "all" just log Parse and the first > Execute? I think I like that suggestion. IMHO the client/server interaction is often worth reviewing as part of a performance analysis, so I do want to include all of that detail, but it sounds like a good idea to be able to turn off the noise once that aspect has been examined. How would that suggestion work when we use log_min_duration_statement? Oliver, would it be possible to show a simplified call sequence and what you would like to see logged for each call? That would simplify the process of gaining agreement and would give a simple spec for me to code. We're into beta now, so I don't want to stretch people's patience too much further by changes in this area. I ask you since I think you have a better grasp on the various protocols than I do. I'll work on a further recoding of what we have been discussing. Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: