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
