Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!jmcarli
From: jmcarli@PacBell.COM (Jerry M. Carlin)
Newsgroups: comp.databases
Subject: Re: PICK dbms/os on UNIX
Message-ID: <1991Jun12.034839.25161@PacBell.COM>
Date: 12 Jun 91 03:48:39 GMT
References: <1991Jun10.223018.26414@ringer.cs.utsa.edu> <10628@idunno.Princeton.EDU> <1991Jun11.224403.9172@ringer.cs.utsa.edu>
Sender: news@PacBell.COM (Pacific Bell Netnews)
Organization: Pacific * Bell
Lines: 29

In article <1991Jun11.224403.9172@ringer.cs.utsa.edu> geckhard@ringer.cs.utsa.edu (Gary Eckhardt) writes:
>An Example:  In PICK, you use the dictionary approach to data, specifying
>what that data looks like via formats, etc.  The only limitation was that
>a dictionary could not go beyond the boundaries of the data file, i.e. I
>could not include a dictionary item that was actually a data element from
>another data file...

Pick for many years has had the "T-file translate" that would do exactly
that. You include a field in the "master" file that points to a subsidiary
file and then you can do what in SQL terms would be a 'join' using the
key field. 

>The database was approximately 80 Megabytes or so.  We were close to
>filling up a 100 meg disk.  This inefficiency has been demonstrated
>to be the same across two different platforms that I've seen it run
>on. 

A couple of things would cause this slowness. The basic cause is typically
choosing a bad 'modulo'. All Pick files are hashed and if the size of the
primary area is too small everything goes into a doubly-linked list and
this can cause horrendous slowness. The other cause of slow restore times
is resetting the 'modulo' which causes a lot of recalculation.

Actually the primary performance problem I used to have was lack of
secondary indicies which caused a long delay for each retrieval. I 
believe this is now fixed.
--
Jerry M. Carlin	(415) 823-2441 jmcarli@srv.pacbell.com
To dream the impossible dream. To fight the unbeatable foe.