Re: statement logging / extended query protocol issues

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