- </sect3>
- <para>
- Zebra computes - unless otherwise configured -
- the exact hit count for every APT
- (leaf) in the query tree. These hit counts are returned as part of
- the searchResult-1 facility in the binary encoded Z39.50 search
- response packages.
- </para>
- <para>
- By setting an estimation limit size of the resultset of the APT
- leaves, Zebra stoppes processing the result set when the limit
- length is reached.
- Hit counts under this limit are still precise, but hit counts over it
- are estimated using the statistics gathered from the chopped
- result set.
- </para>
- <para>
- Specifying a limit of <literal>0</literal> resuts in exact hit counts.
- </para>
- <para>
- For example, we might be interested in exact hit count for a, but
- for b we allow hit count estimates for 1000 and higher.
- <screen>
- Z> find @and a @attr 11=1000 b
- </screen>
- </para>
- <note>
- The estimated hit count facility makes searches faster, as one
- only needs to process large hit lists partially.
- It is mostly used in huge databases, where you you want trade
- exactness of hit counts against speed of execution.
- </note>
- <warning>
- Do not use approximative hit count limits
- in conjunction with relevance ranking, as re-sorting of the
- result set obviosly only works when the entire result set has
- been processed.
- </warning>
- <warning>
- This facility clashes with rank weight, because there all
- documents in the hit lists need to be examined for scoring and
- re-sorting.
- It is an experimental
- extension. Do not use in production code.
- </warning>
+ <para>
+ Zebra computes - unless otherwise configured -
+ the exact hit count for every APT
+ (leaf) in the query tree. These hit counts are returned as part of
+ the searchResult-1 facility in the binary encoded Z39.50 search
+ response packages.
+ </para>
+ <para>
+ By setting an estimation limit size of the resultset of the APT
+ leaves, Zebra stoppes processing the result set when the limit
+ length is reached.
+ Hit counts under this limit are still precise, but hit counts over it
+ are estimated using the statistics gathered from the chopped
+ result set.
+ </para>
+ <para>
+ Specifying a limit of <literal>0</literal> resuts in exact hit counts.
+ </para>
+ <para>
+ For example, we might be interested in exact hit count for a, but
+ for b we allow hit count estimates for 1000 and higher.
+ <screen>
+ Z> find @and a @attr 11=1000 b
+ </screen>
+ </para>
+ <note>
+ <para>
+ The estimated hit count facility makes searches faster, as one
+ only needs to process large hit lists partially.
+ It is mostly used in huge databases, where you you want trade
+ exactness of hit counts against speed of execution.
+ </para>
+ </note>
+ <warning>
+ <para>
+ Do not use approximative hit count limits
+ in conjunction with relevance ranking, as re-sorting of the
+ result set obviosly only works when the entire result set has
+ been processed.
+ </para>
+ </warning>
+ <warning>
+ <para>
+ This facility clashes with rank weight, because there all
+ documents in the hit lists need to be examined for scoring and
+ re-sorting.
+ It is an experimental
+ extension. Do not use in production code.
+ </para>
+ </warning>
+ </section>
projects / idzebra-moved-to-github.git / blobdiff