HP3000-L Archives

March 1998, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
WirtAtmar <[log in to unmask]>
Reply To:
WirtAtmar <[log in to unmask]>
Date:
Tue, 31 Mar 1998 19:06:56 EST
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
Ken writes:

> ..... except now with B-Trees there is one exception:
>  Superchain without accurate chain count.....  in which case
>  perhaps it could default to the total number of records in the
>  dataset;  at least you would have a "not to exceed" value,
>  even if the actual records qualified by the B-Tree search might
>  be a lot less....

No, you still can determine how many items are in the superchain, if you
choose to do so. It's just a mode selection.

One thing that I didn't make clear in my first posting is that you can only
determine the percentage complete information for the driving (or leftmost)
dataset in a multi-dataset join, a priori. The number of items any particular
value in the driving dataset joins to the other dataset(s) is unknown until
you actually begin the "orthogonal" finds on the second dataset, value-by-
balue, thus you can't actually know in advance the "total" number of records
you'll find. However, that doesn't seem to be that much of a problem to the
user. He or she really just wants to see if the d*mned thing is moving -- and
how much longer it might take.

An estimated percentage complete -- and the number of "driving" values -- is
all that you can present with efficiency (unless you wanted to do the
multifind twice, once to accurately determine the number of records and once
to do it for "real," showing the display :-).

Wirt Atmar

ATOM RSS1 RSS2