On Mon, 2005-09-05 at 15:38 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq