Improving FP performance?

[Bob Stockler]

Steve Bergman wrote (on Tue, Jun 06, 2006 at 03:11:15PM -0500):

| Thanks, Walter, for the reply.  The RAID array wouldn't help a whit in
| this case.  With 2GB of memory, the data all fits in the cache.  You're
| right about my being more familiar with the internals of PostgreSQL.
| But in this case I was thinking of Cobol and C/Isam files and the need
| for a rebuild/export/import from time to time.  IIRC from years back,
| Filepro marks records for deletion but does not immediately remove
| them.

I don't understand what you mean by your above statement.  When a
filePro record is deleted the space in the "key" (and "data" if
used) file is not recovered, but is blanked out, and that space
then becomes available for use by a newly created record.

|        However, if the file is growing, it *can* reclaim that space for
| new records. These files would be growing.

It uses the freed space even if the file is not growing.  When a
record is deleted the space it occupied in the "key" (and "data"
if used) file becomes the candidate for the next record added.

I think filePro uses info stored in the first 20 bytes of a "key"
record to determine which deleted/unused record space to use for
the next added record, using a last deleted - next used algorithm,
and this info is stored in the filePro "info" first file record
in its "key" file (as to what is "next-to-be-used").

Running $PFPROG/fp/lib/freechain on a filePro file will cause the
"next-record-to-be-used" to revert to "from-front-of-file" order.

I've written a filePro program called "delate" that removes all of
the deleted records from a filePro file, appending an unused free
record at the end of the filePro file.  It's available at;

  ftp.jpr.com

in the "filePro" directory as "deflate.tgz" (it maintains the data
in the 20-byte header of each record).

Bob


-- 
Bob Stockler  +-+  bob at trebor.iglou.com  +-+  http://members.iglou.com/trebor