AW: AW: AW: Combining cursors

[Robert Brenstein]

>on 12/1/03 9:06 PM, Florian Bogeschdorfer at fb at memedia.de wrote:
>
>>  I don't think that is the same while you may go both ways to get the result.
>>  But I would like that very much too. In spite of searching the whole DB just
>>  search a cursor, kind of focussing in. Very nice Ruslan!
>
>In fact all is not so easy.
>
>When I search the whole table, I can easy use index of field.
>
>If I have some SELECTIONS of records for this table,
>Then I have 2 ways:
>
>1) using this selection SCAN the table and check values
>
>2) still use the same THE WHOLE index, execute search as usual,
>And make additional step -- built intersections of 2 sets.
>
>So it is not 100% speed up!
>
>All depends on kind of query, number of records on table and number of
>records in the cursor.
>
>--------
>Another case, when cursor build own RESULT table. Then it can have smaller
>size than original. On the other hand it DO NOT have indexes. Of course I
>can build indexes, but this is again time.
>
>Measure what way is better is VERY HARD task. :-)
>

Searching cursors has been brought up more or less regularly for a 
number of years and sort of promised for version 2 as far as I recall 
;)

I may think naively and plead ignorance at this level of operation, 
but if asked to search an existing cursor, can't V create a virtual 
field and set to to 0 or 1 and then search the entire db but 
including only results with true in that virtual field? You could 
even add a new flag to search request that would specify whether the 
resulting cursor can be searched and precreate that in the first 
search.

I may be wrong, but I don't think most of people asking for this 
feature look to boost performance but to expand user-end features. 
For example, our user may do a search and then follow up  with a 2nd 
search that narrows down the result (if the first search was too 
broad).

Robert Brenstein