× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Ah, ok I'm following you here...

And I see how this ties in with your ALLOCATE(0) recommendation...

Data I/O is expensive, Data I/O is expensive, Data I/O is expensive,

Why some of us have to relearn that? ;)

I'll do some more testing to see what I can find.

Thanks again!
Charles

On Thu, Jul 22, 2010 at 3:34 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

  But only an improvement for the scan processing, not for the
overall query processing.  Even if measuring actual CPU-time versus
clock-time, the fixed-costs will skew downward any potential for
improvement.

  The I\O is an effective fixed-cost for the table scan, increased
by a little more than 6MB in the given scenario for changing to add
the two-byte varying length.  The CPU cost is near insignificant for
the comparisons against the non-matched bytes across the storage
which will already have been paged into memory; paged with similar
characteristics for both scenarios.  Each will have similar CPU
costs for everything other than the text string scanning.

  According to the percentages given, instead of looking for an
overall percent improvement, you are looking for an improvement only
with character scanning.  Subtract from each test scenario, the
overall cost of selecting a single-byte comparison which will either
never match any row from or will match every row on the first byte;
a one-byte compare with no match includes the cost of doing all of
the I\O, but with the most minimally complex scan [compare of each
byte for length of data or field], and a one-byte compare where
every row will match on the first byte includes the cost of doing
all of the I\O while ensuring only one single-byte compare.  To
prevent actual row selection, the query should be a SELECT COUNT(*)
summary so neither does any actual row\data retrieval.  Finally,
review the percent difference between the two scenarios after
adjustment [for removal of the fixed I\O cost and an effective
minimal scan cost], for which an effective difference should be in
consideration of only the scanning costs.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.