Re: statement logging / extended query protocol issues

On Mon, 2005-09-05 at 15:38 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > +     /*
> > +      * If we re-issue an Execute protocol request against an existing
> > +      * portal, then we are only fetching more rows rather than 
> > +      * completely re-executing the query from the start
> > +      */
> > +     if (!portal->atEnd)
> > +         subsequent_fetch = true;
> 
> That strikes me as a completely bogus test for a "re-issued" execute.
> Did you mean !atStart?

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.

> Also, why is it a good idea to report the number of rows fetched in
> some cases (and not others)?

The number of rows fetched seemed particularly important on a FETCH
operation. Although they are logically part of the same query, some
queries have a lengthy pre-execution preparation time (e.g. sort) and
others don't.

(To Oliver:)
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.

If we see

FETCH unnamed ROWS 1
FETCH unnamed ROWS 1
FETCH unnamed ROWS 1

we'd know the fetchsize was inappropriately set and correct it.

I guess we could add in a number of rows on the other log lines also if
people want that. I like the idea... it would tell us which queries are
causing huge retrievals.

Best Regards, Simon Riggs