Hopefully I've got this right...
When the following query is performed on a table with 500,000 rows:

select first 50 skip 50 * from table where condition = value;

The entire recordset is created based on joins, where conditions, etc.
Then 50 records are skipped, 50 records are returned, and the remaining
memory is deallocated, ready for the next query.

How hard would it be to add an internal conduit to the external interface to
give some information(namely, number of records) about the entire recordset,
before the skipping and first operations occured?

The support appears to be in the source:...
----------------
(/src/jrd/rsc.cpp, lines 698 - 717)

case rsb_first:
max_records += ((IRSB_FIRST)impure)->irsb_count =
MOV_get_int64 (EVL_expr (tdbb, (JRD_NOD) rsb->rsb_arg [0]),
0);

if (((IRSB_FIRST)impure)->irsb_count < 0)
ERR_post (gds_bad_limit_param, 0);

rsb = rsb->rsb_next;
break;

case rsb_skip:
max_records += ((IRSB_SKIP)impure)->irsb_count =
MOV_get_int64 (EVL_expr (tdbb, (JRD_NOD) rsb->rsb_arg [0]),
0);

if (((IRSB_SKIP)impure)->irsb_count < 0)
ERR_post (gds_bad_skip_param, 0);
((IRSB_SKIP)impure)->irsb_count++;

rsb = rsb->rsb_next;
break;

---------------
I'll be the first to say it - I know very little about C++, or the way
Firebird is written.
By the looks of it, 'max_records' gets incremented (+=) with each record
falling in either the 'first' or 'skip' case sections.
Does that continue to get incremented anywhere else? Perhaps the 'scrolling
cursor' sections do a high-speed record count that can be passed out?
Is the size of the recordset that the 'first' and 'skip' sections rattle
through, known.

Sorry if it's too early in the morning for questions like these...

Nige




Nigel Weeks
Tech Support & Systems Developer
nweeks@...
www.examiner.com.au
71 - 75 Paterson Street
Launceston
Tasmania 7250
Australia
Phone: 03 6336 7234