Browse Prior Art Database

Method and Systems for Performance Improvement When Determining the Data Space Location with Code Bursts for Partitioned Tables

IP.com Disclosure Number: IPCOM000100069D
Original Publication Date: 2005-Mar-15
Included in the Prior Art Database: 2005-Mar-15
Document File: 2 page(s) / 46K

Publishing Venue

IBM

Abstract

By adding a code burst into the cursor, the code burst can determine the correct data space faster when inserting records into the data space.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 89% of the total text.

Page 1 of 2

Method and Systems for Performance Improvement When Determining the Data Space Location with Code Bursts for Partitioned Tables

A Partitioned Table is constructed with a number of data spaces. Each data space contains the records relevant to specific ranges of data. The data is directed towards the specific data space based on the key, or keys (which are fields of the record) of the data being inserted into the Partitioned Table. A process must be defined to determine the physical location of the record. One solution to determine the data space location is to create an external program which determines the correct data space from comparing the key field (partition data) with the range data input when the Partitioned Table was created. The performance for this type of processing of each record is very slow.

By adding a code burst into the cursor, the code burst can determine the correct data space faster when inserting records into the data space.

     When a partition file is created, there are check constraints created for each physical file member so records cannot accidentally be added to the wrong physical file member that makes up the partition file. When the cursor for the partition file is created, we take the templates for the check constraints for all the physical files that make up the partition file and combine them in a way that can determine the physical file that a record should go to from the partition key field(s). These merged and manipulated templates are used to generate code bursts that will perform the logic to compare the partition key field in record and come up with the physical file member that the record should be placed in.

Example...

Partition file with 3 partitions PF Partition key as FLD1 Partition Ranges -9999 <= FLD1 < 0 0 <= FLD1 < 1000 1000 <= FLD1 < 10000 Physical file members PF00001 PF00002 PF00003

Check constraints get FLD1 get FLD1 get FLD1 templates perform if FLD1 >= -9999 if FLD1 >= 0 if FLD1 >= 1000 on each member if FLD1 < 0 if FLD1 < 1000 if FLD1 < 10000 return ok return ok return ok

else else else

return bad return bad return bad

else else else

return bad return bad return bad

Partition Selection Get FLD1 templates that are if FLD1 >= -9990 the check constraint if FLD1 < 0 templates merged and return 1 manipulated to perform if FLD1 >= 0 this logic, if FLD1 < 1000 return 2

if FLD1 >= 1000

if FLD2 < 10000

return 3

return 0

1

Page 2 of 2

     The Partition Selection code is generated at cursor create time and run agains...