HP3000-L Archives

December 2005, Week 3

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:
Jerry Fochtman <[log in to unmask]>
Reply To:
Jerry Fochtman <[log in to unmask]>
Date:
Tue, 20 Dec 2005 08:48:27 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (82 lines)
Jim,

In all the testing we've done for performance turning of code with various 
datasets/etc.
I've not stumbled on anything that suggests that if a dataset were to have 
say 3
search fields, the placement of those fields within the entry would affect 
I/O performance.
Keep in mind that the internal chain pointers are always located ahead of 
the data
portion of the entry anyway, regardless of where the field is on the 
record. and that's the area that's used to walk the paths.

This does not take into consideration if any of the search fields are 
sorted and how
the size of the extended sort area (remainder of the entry following the 
sort field)
impacts the comparison logic cost when inserting entries in the dataset or 
changing
the key value itself (via update), and the impact this has on the 
performance of the
operation, which could be interpreted as a cost of I/O.

Obviously smaller records, or less search fields could result in more 
compact/denser
storage objects, resulting in more entries retrieved per physical 
I/O.   But then this
assumes a specific access pattern which may or may not be predictable.

As always with any performance issue, YMMV... :-)


At 05:41 AM 12/20/2005 -0800, Jim Phillips wrote:
>I was just adding a new detail data set to an existing
>Image data base and the following question occurred to
>me:  Does it make any difference in terms of I/O speed
>or efficiency where the search items (key fields) are
>located in the data set?
>
>Traditionally, the data sets I have seen have all the
>search items at the beginning of the data set:
>
>Key-Item1 (Key1-Master)
>Key-Item2 (Key2-Master)
>Data-Item1
>Data-Item2
>...
>Data-ItemN
>
>Now is this just convention or is it because it is
>"better" (and define "better")?
>
>I mean, couldn't you layout a detail data set like
>this:
>
>Data-Item1
>Data-Item2
>Key-Item1 (Key1-Master)
>Data-Item3
>...
>Key-Item2 (Key2-Master)
>...
>Data-ItemN
>
>Would there be any adverse effects from such a data
>structure?
>
>Inquiring minds want to know...
>
>Jim Phillips
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2