HP3000-L Archives

February 2003, Week 2

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:
fred White <[log in to unmask]>
Reply To:
fred White <[log in to unmask]>
Date:
Wed, 12 Feb 2003 12:19:29 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (38 lines)
On Wednesday, February 12, 2003, at 11:47 AM, John Clogg wrote:

> Michael,
> I most certainly agree that absolute rules (never do this, always do
> that)
> are seldom appropriate.  Fred White addressed the question of sorted
> chains
> quite well in his paper "The Three Bears of Image", which I assume can
> be
> found at the Adager web site.

Yes.

> The upshot of his message is that sorted chains can be a resource hog
> if misused, but are useful if applied appropriately.

If the sorted chain is very long, DBPUTs will be slow unless the new
sort field value is near the end of the chain.

Of course, a dataset with several sorted paths will further slow down
DBPUTs.

In case it matters to your decision, I remind you that entries to
non-sorted paths are added to the end of the appropriate chain. This
keeps those chains in chronological order. This can be taken advantage
of when searching such a chain for a particular entry. If you know that
it's an "old" entry, use forward chained reads. If you know it's a
"recent" entry, use backward chained reads.
Obviously, this can be very important if the chain is long.

These considerations are best addressed at application design/re-design
time.

FW

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

ATOM RSS1 RSS2