Project

General

Profile

Support #6707

evaluate the effectiveness of the current approach to ProgressiveResults

Added by Greg Shah over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version:

Related issues

Related to Database - Bug #4931: possible ProgressiveResults performance improvement New

History

#1 Updated by Greg Shah over 1 year ago

Currently ProgressiveResults always starts with a set size of 1. This was done because the following idiom was seen:

FOR EACH something WHERE ...:
   ...
   LEAVE.
END.

// this code may also use something

The idea is that there may be code in the block to process something but that there is a LEAVE (conditional or unconditional) such that we never iterate the FOR loop. If we got all records back (or a large number), then this use case would be costly compared to the 4GL.

However, we don't know if this is generally a common use case. It was seen often in old code but how often is it really hit?

We should track (maybe with JMX?) the number of results actually used in a given ProgressiveResults query so that we can evaluate the effectiveness of this approach.

#2 Updated by Alexandru Lungu over 1 year ago

  • Related to Bug #4931: possible ProgressiveResults performance improvement added

Also available in: Atom PDF